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(57) Abstract 

The invention relates to a simulator for simulating the performance of an intelligent 
network (IN), with the following components: 1. a module (20 J, 301, 401) for simulating 
any IN-typical runs (traffic simulator) in accordance with the rules of traffic theory; 2, a 
module (202, 302, 402) for event-oricntcd simulation of the service control point (SCP 
simulator) using process models; 3. elements (203. 204. 304-307, 406-409) for transferring 
data between the modules; 4, elements (207. 311. 416. 208-212, 312-317, 411-415) for 
inputting and storing the network configuration, communications service specification and 
other simulation parameters and transferring them to the relevant modules and 5. elements 
(205-207, 308-310, 417-420, 423) for outputting and/or storing the simulated data. Modules 
(303, 403, 503, 404, 502)for simulating the SS7 signalling system, preferably taking into 
consideration the functionalities of the service relay point (SRP) (103), and for simulating 
the overload defence mechanisms widiin the IN are also provided. The simulation models 
communicate with transfer files in a file mode or are linked by a common organisation 
programme, the on-line simulator, in an on-line mode. Central elements of the simulator 
in the on-line mode are event calendars in which events to be processed by the simulation 
modules are entered in the order in which they are processed and which enable processes 
which in reality are carried out in parallel to be processed in a sequence. The inventive IN 
simulator makes it possible to analyse the performance of an IN in its present or a future state 
in order to advantageously identify weak points and increase the efficiency of the IN. 
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(57) Ziisammenfassuiig 

Die Erfindung betrifft einen Simulator zur Simulation dcr Perfonnance eines Intellig^ten Netzwerks (IN), der folgende Komponenten 
aufweist h ein Modul (201, 301, 401) zur Simulation beliebiger IN-typischcr Ercignisfolgen (Verkehrssimulator) nach den Regcln der 
Verkehrtheoric; 2. einem Modul (202, 302. 402) zur ereignisorientiertcn Simulation des Service Control Point (SC3*-Simulator) untcr 
Verwendung von ProzcBmodellen; 3. Mittcl (203, 204. 304-307, 406-409) zur Datenfibergabe zwischen den Modulcn; 4. Mittel (207, 311, 
416, 208-212, 312-317, 411-415) zur Eingabe und Speicherung der Netzkonfiguration, Kommunikationsdienstespezifikation und sonstigen 
Simulationsparametcm sowie deren Obergabe an die entspiechenden Module; 5. Mittel (205-207, 308-310, 417-420, 423) zur Ausgabe 
und/oder Speicherung der simulierten Daten. Weiterhin sind Module (303, 403, 503, 404, 502) zur Simulation des SS7-Zeichengabcsystems, 
vorzugswcise unter Bertlcksichtigung der Funktionalitaten des Service Relay Points (SRP) (103), sowie von Crberlastabwehimechanismen 
innerhalb des IN vorgesehen. Die Simulationsmodule kommunizieien in einem Datei-Modus fiber Obeigabedateien oder sind in einem 
Online-Modus durch ein gemeinsames Organisationsprogramm. den Online-Simulator, verknflpft. Zentrale Elemente des Simulators im 
Online^Modus sind Ereigniskalender, in denen von den Slmulationsmodulen abzuaibeitende Ereignisse in der Reihenfolge ihrer Bearbeitung 
eingetragen sind und die die Umsetzung in der Realimt parallel ablaufender Prozessc in eine sequcntielle Bearbeitung enndglichen. Mit 
dem erfindungsgem^fien IN-Simulator kann die Performance eines IN in gegenwMiger und zukOnftiger Realisierung vorteilhaft ennittelt 
werdcn, um Schwachstellen aufeuspftren und die Effizienz des IN zu steigem. 
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Simulator zur Simulation eines Intelligenten Netzwerks 
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Tedmisches Gebiet: 

5 Die Erfindung betriffi einen Simulator zur Simulation eines Intelligenten 
Netzwerks, insbesondere zur Auffindung und Analyse von Schwachstellen, 
zum Testen von Netzkonfigurationen und/oder Steuerungsmechanismen sowie 
zur AufBndung von Moglichkeiten zur Steigerung der Leistungsfahigkeit des 
Netzes. 

10 

Hintergrund der Erfindung: 

Der BegrifF Intelligentes Netz (IN) steht weltweit fiir das Konzept einer fur 
alle Telekommunikationsnetze giiltigen Netzarchitektur. Kemelement dieses 

15 Konzepts ist ein softwaredefiniertes individueUes Kommunikationsprofil fiir 
die Kunden der Telekonmiunikationsdienste. Im IN sind wichtige Funktionen 
und Daten zentralisiert und werden nur in einem oder wenigen Knoten 
bereitgesteUt. Diese Ftmktionen und Daten betreffen beispielsweise 
Informationen. wie ein Anruf mit einer IN-spezifischen R ufa u mm er in 

20 Abhangigkeit von seinem Ursprungsort. der angewahlten Rufn um mer, der 
Tageszeit imd/oder sonstigen Parametem behandelt werden soil, z.B. ob und 
an welchen Netzteilaehmer ein Anruf weitervermittelt, ob imd axif welche 
Ansagen ein Anruf geschaltet werden soil oder ob ein Anruf lediglich gezahlt 
wird. Mit Hilfe des Intelligenten Netzes wird ein inteHigenter, verzwdgter 

25 Datenbankzugriff von einer Mehrzahl von Dienstzugangspunkten (Service 
Switching Point. SSP) auf in einem oder wenigen zentralen Knoten (Service 
Control Point, SCP) zur Dienstesteuerung abgelegte Daten und Funktionen 
realisiert. 

30 Das Intelligente Netz liegt dabei organisatorisch als zentralistisches Netz liber 
dem Telefonnetz und steUt Intelligenz zum Auf- und Abbau von Verbindungen 
iiber das Telefonnetz zur Verfugung. Die SchnittsteUe zwischen Telefonnetz 
und Intelligentem Netz ist dabei durch die SSPs gebildet. bei welchen Anrufe 
mit IN-spezifischen Rufinunmem eingehen und nach Erhalt der 

35 Weiterbehandlungsinformation vom SCP gemaB dieser Anweisungen 
weiterbehandelt werden, z.B. an eine vom SCP mitgeteilte Rufiiummer 
weitervermittelt werden. 
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Im InteUigenten Netz werden die emzdnen Funktionskomplexe in separaten 
Systemebenen realisiert. IN-Transport- und Vermittliuigsfunktionen werden 
in der SSP-Ebene (Service Switxiiing Point) realisiert, 
Dienstesteuerungsfunktionen und Verwaltung der Dienstdaten in der SCP- 
5 Ebene (Service Control Point) und Diensteverwaltungen im Service 

Management System (SMS). Die Kommunikation zwischen der SSP- und der 
SCP-Ebene erfolgt iiber das Zeichengabesystem Nr. 7 (SS7-System), liber 
welches IN-spezifische Nachrichten zur Anrufbehandlung verschickt werden. 
Der Zeichengabetransfer und dessen Steuerung innerhalb des SS7-Systems 

10 wird durch einen oder mehrere Service Transfer bzw. Relay Point (STP bzw. 
SEP) realisiert. Der STP bzw. SEP dient dabei zur Vermittlung und 
Verteilung (Routing) der Nachrichten im zentralen Zeichengabekanal 
zwischen dem SCP und dem SSP. Der STP bzw. SEP kann zudem als Gateway 
fiir Nachrichten dienen, die IN-Dienste eines anderen Netzbetreibers betreffen 

15 und vom SCP eines weiteren IN bearbeitet werden mxissen. Wichtiges 

Routing-Kriterimn einer IN*Nachricht ist ihr globaler Titel (global title); die 
STP/SBP-Ebene realisiert dabei die Global Title Translation (GTT). 

Die SSP-Ebene verfiigt iiber Moghchkeiten, IN-Verbindungen zu erkennen, 
20 Z.B. anhand der Rufiiummer, und zu unterstiitzen. Bei diesen Verbindxmgen 
miissen Informationen bei einem SCP fiir den weiteren Verbindxmgsaufbau 
abge&agt werden. Der SCP enthalt Programme und die dazugehorigen Daten 
zur Steuerung der Dienste. Desweiteren sammelt der SCP Daten zux 
Vergebuhrung und zu statistischen Auswertungen. Mehrere SSP greifen auf 
25 einen zentralen SCP zu. Dem SCP iibergeordnet ist das Service Management 
System, welches die Administration der IN-Dienste und IN-Komponenten 
enthalt. 

MLt Hflfe eines Intelligenten Netzes werden beispielsweise folgende IN- 
30 Dienste reaUsiert: 

Televotum (TV): Der Dienst Televotum ermoghcht dem DienstteHnehmer, die 
Anzahl der Anrufe unter seiner Televotum-Eufiiiunmer registrieren zu lassen. 
In einer Variante dieses Dienstes erfolgt eine Anfirage an den SCP bei jedem 
35 Anruf, in einer weiteren Variante werden die Anrufe im SSP vorgezahlt, wobei 
eine Anfrage an den SCP bei jedem k-ten Anruf erfolgt. Unabhangig von der 
gewahlten Variante wird jeder im IN-System eintrefifende TV-Ruf registriert. 
Dabei kann in Abhangigkeit vom aktiven Verkehrsfuhnmgsprogramm zudem 
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jeder n-te Ruf speziell behandelt werden, z.B. nach der Registrierung zu einer 
vom Dienstteiliiehmer festgelegte Zieladresse weitergeleitet werden. Alle 
anderen Anrufe fiihren nach der Registrierung zu einer Ansage, die ebenfalls 
im Verkehrsfuhrungsprogramm vom Dienstteilnehmer festgelegt wurde. 

5 

Freephone (FPB): Der Dienst Freephone gibt Dienstnutzem die Moglichkeit, 
den "Dienstteilnehmer" gebuhrenfirei anziunifen. Die gesamten Gebtihren 
werden vom Dienstteibaehmer iibemommen, 

10 UniverseEe Rufiiummer (UNU): Mit dem Dienst Universelle Rufaummer ist 
es mo^ch, daB ein DienstteiLiehmer unter einer einheithchen, 
ortsnetzunabhangigen Rufiiummer iiberall erreichbar ist. Die Gebuhren fur 
derartige Verbindungen konnen abhangig von der Festlegung des 
DienstteiLnehmers vom Anrufer allein oder aufgeteilt auf Anrufenden xmd 

15 Angerufenem erhoben werden. 

Tele-Info-Service (TIS): Der Tele-Info-Service ermoghcht Anrufem den Zugang 
zum Informationsangebot des DienstteiLnehmers iiber dessen 
Ansageeinrichtungen oder in direktem Dialog. Die Gebuhren werden dem 
20 Anrufer berechnet und konnen anhand der verbindungsbezogenen 

Informationen zwischen Netzbetreiber und Dienstteilnehmer aufgeteilt 
werden. 

Dariiberhinaus sind weitere Dienste moghch, z.B. Zuweisung einer 
25 Rufiiummer zu einem Kunden anstelle zu einem AnschluB und Leitxmg aller 
Anrufe mit dieser Rufiiummer an den Aufenthaltsort des Kxmden. In diesem 
Sinne sind auch Mobilfimknetze InteUigente Netze. 

Der Dienstteilnehmer hat die Moglichkeit, seinen Dienst anhand weiterer 

30 Dienstmerkmale zu spezifizieren, z.B. 

Anruf-Umlenkung (Rerouting): Wenn sich der angewahlte TeUnehmer nicht 
meldet oder die Nummer besetzt ist, wird der Anruf entweder auf eine Ansage 
oder auf eine andere Nummer durchgeschaltet. Dieser Vorgang kann bis zu 
einer vorgeschriebenen Anzahl von Versuchen wiederholt werden, ansonsten 

35 wird der Anruf abgewiesen. 

Anrufbegrenzung: Ubersteigt die Anzahl der Anrufe zu einer Zielrufiiummer 
innerhalb eines Zeitraums die vom Dienstteilnehmer vorgegebene 
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Begrenzung, werden die iiberzahligen Aorufe auf definierte alternative 
Zielrufiiunimem oder Ansagen gefuhrt. 

Zeitabhangige Zielansteuerung: Der Anrufiszeitpunkt wird gegen die 
5 periodischen und/oder temporaren Zeitfenster gepnift. Wird kein giiltiges 
Zeitfenster gefunden, fiihrt der SCP den IN-Anruf zu einer 
Standardhinweisaiisage, ansonsten wird zum Anrufeiel oder zum nachsten 
Dienstmerkmal verzweigt, 

10 Urspnmgsabhangige Zielansteuerung: Die Netzursprungsinformation wird 
mit der im Verkehrsftdirungsprogramm hinterlegten Ursprungsinfomiation 
verglichen. Wird keine tlbereinstinmiung gefunden, fiihrt der SCP den Anruf 
zu eiaer Standardhinweisansage, ansonsten wird zum Anrufeiel oder zum 
nachsten Dienstmerkmal verzweigt. 

15 

Anrufverteilung: Das Dienstmerkmal Anrufvrerteilung erlaubt die Definition 
individueUer Quoten, nach denen Anrufe auf verschiedene Ziele verteilt 
werden. 

20 Wird ein Anruf auf eine Ansage geschaltet, fongiert der SSP als fiktiver 
KommumkationsteLlnehmer. Der SSP unterstiitzt netzleistungsbezogene 
Standardhinweisansagen und Ansagen, die als Anrufsziel angesteuert werden 
konnen. Die einzelnen Ansagen haben eine begrenzte Zahl von 
Abfirageplatzen. Bei Belegung aller Abfirageplatze werden die uberzahUgen 

25 Anrufe abgewiesen. Jede Ansage ist durch eine maximale Abhorzeitdauer und 
Anzahl von Wiederholungen begrenzt. 

Fiir die meisten IN-Dienste, z.B. FPH, UNU, TIS und TV ohne Vorzahlung, 
besteht die Aufgabe des Intelligenten Netzes darin, die gewahlte IN-Nummer 
30 in Abhangigkeit von definierten Dienstparametem im 

Verkehrsfiihrungsprogramm in eine reale Nummer zu iibersetzen. Dieses 
erfolgt nach folgendem prinzipiellen Ablauf: 

1. Im SSP werden die ersten Ziffem der gewahlten Telefonnummer 
35 ausgewertet und der IN-Dienst erkannt. Der SSP sendet eine Anfrage zur 

weiteren Rufbehandlung mit der Nachricht PROVIDE INSTRUCTION an den 
SCP. Die Nachricht enthalt als Parameter die vom Dienstnutzer gewahlte IN- 
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Teilnehmerrufiiuinmer (CALLED-PARTY-ADDRESS) und die Rufiaummer des 
Anrufes (CALLING-PARTY-ADDRESS) . 

5 2. Im SCP wird durch die Nadmcht PROVIDE-INSTRUCTION das 

DienstlogLkprogramm fiir den entsprechenden EN-Dienst angesprochen* Das 
iiber CALLED-PARTY-ADDRESS adressierte teilnehmerspezifische 
Verkehrsfuhrungsprogramm wird angesteuert. Als Ergebnis wird im hier 
beschriebenen Normfall ein Ziel fur den Verbindungsaufbau ermittelt, das 

10 kann eine Ru&iummer oder eine Ansage sein. Zusatzlich konnen sich axis dem 
Verkehrsfuhrungsprogramm Anforderungen zur Verbindungsiiberwachung 
ergeben, wie das Uberwachen von "TeiLiehmer besetzt" vmd "Teihiehmer 
antwortet nicht". Der SCP sichert die Ergebnisse im verbindnngsspezifischen 
Kontext und sendet die Nachricht CREATE-JOIN und MONITOR an den SSP. 

15 Die Nachricht enthalt als Parameter CALLED-PARTY-ADDRESS und 
EVENTUSTE, die die zu iiberwachenden Ereignisse spezifiadert. 

3. Im SSP wird zu der mit CREATE-JOIN iibergebenen Zielrufiiummer uber 
das Femsprechnetz ein Verbindungsaufbau zum B-Teilnehmer durchgefiihrt 

20 oder auf eine Ansage geschaltet, 

4. Der SSP iiberwacht den Verbindungsaufbau zum B-Teihiehmer, wenn dies 
in der EVENTUSTE spezifiziert wurde. Wenn der B-Teilnehmer nicht 
reagiert, wird die Verbindung in Richtung B-Teilnehmer nach Ablauf eines 

25 Timeouts ausgelost und der SCP mit der Nachricht EVENT iiber das 
aufgetretene Ereignis informiert. 

5. Aus dem Verkehrsfiihrungsprograiimi wird ein Altemativziel bestimmt 
(Rerouting) und eine Nachricht CREATE-JOIN und MONITOR mit 

30 entsprechenden Patametem an den SSP gesendet. 

6. Im SSP wird zu der mit CREATE-JOIN iibergebenen Zielrufiiummer iiber 
das Femsprechnetz ein Verbindimgsaufbau zum B-Teibiehmer durchgefiihrt, 
oder auf eine Ansage geschaltet. Nach Melden des B-Teilnehmers wird die 

35 Verbindung durchgeschaltet. 

7. Bei Gesprachsende werden im SSP die im SCP benotigten Daten fur die 
Vergebiihrung und Statistik zusammengesteUt und mit der Nachricht 
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EVENT(CALL-END) iibertxagen. IM SSP wird mit einem Timer die 
Bestatigung dieser Nachricht durch den SCP iiberwacht. 1st bis zum Ablauf 
des Tuners fceine Bestatigung eingetroffen, wird das Senden der Nachricht 
EVENT(CALL-END) wiederholt. 
5 8. Nach Empfang der Nachricht EVENT(CALL-END) sendet der SCP eine 
Nachricht zum Beenden des TCAP-Dialogs. Im SCP wird der 
verbindungsspezifische Kontext reaktiviert. Die empfangenen Timestamps 
werden zusammen mit den im Kontext hinterlegten Daten abgespeichert 
(CallTickets), Sie werden spater zur weiteren Bearbeitung an das SMS 
10 iibertragen. Im SCP gefuhrte Zahler (z.B. fiir erfolgreiche Anrufe) werden 
hochgezahlt (Counter Tickets), 

Die Punkte 4, 5 und 6 in diesem Ablauf treten nur bei einem Rerouting auf. 

15 Um auch bei hohem Verkehrsaufkommen einen ordnungsgemaBen Betrieb des 
IN sicherzustellen, sind innerhalb des IN-Uberlastabwehrmechanismen 
vorgesehen. Die Uberlastabwehr fuhrt dazu, daB der SSP nach bestimmten 
Vorgaben IN-Anrufe ohne Anfirage an den SCP abweist. Beispiele fiir 
tiberlastabwehrmechanismen sind AUTOMATIC-CALL-GAPPING (ACG) 

20 oder die LEAKY-BUCKET-Methode. Es ist eine dienst- und/oder 
zielabhangige tJberlastabwehr moglich. 

Ein Service Control Point ist iiblicherweise ein mehrschichtiges System mit 
einem Hardwarefundament und mehreren, iiblicherweise drei Schichten 

25 Software. Das Hardwarefundament besteht aus einem Computer mit einem 
oder mehreren parallel verarbeitenden Prozessoren mit 
Verbindungsleitungen, Festplatten, Magnetbandem, Terminals und 
Druckem- Die erste Softwareschicht enthalt die Systemsoftware. Die zweite 
Softwareschicht (NODE-Software) enthalt allgemeine Funktionen fiir die 

30 Service AppUcation. Die dritte Softwareschicht besteht aus der Application, 
die die anrufeverarbeitenden Dienste vmterstutzt. Im Falle einer 
Parallelverarbeitungs-Architektur des SCP weist dieser eine Mehrzahl von 
Prozessoren auf, die jeweils eine in sich autarke Einheit mit CPU, 
Hauptspeicher, Stromversorgung und Eingabe/Ausgabe-Prozessor darstellen 

35 und untereinander mit einem Bus-System verbunden sind. 

Die verschiedenen SCP-Software-Schichten enthalten neben 
Betriebssystemprozessen und allgemeinen, nicht unmittelbar zum 
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Betriebssystem gehorenden Prozessen, z,B. zur Kommunikation zwischen den 
Prozessen oder zur effektivenVerwaltung des lofcalen Cache, 
Applikationsprozesse, die fiir die Abarbeitung einer IN-Nachxicht benotigt 
werden. Eiae am SCP ankommende IN-Nachricht durchlauft somit in 
5 verschiedenen Schichten des SCP eine Folge von Prozessen, welche in der 
Generienmg einer IN-Nachricht des SCP an den SSP als Antwort auf dessen 
Anfrage znr Anrufbehandlnng resultiert. Die Prozesse k5nnen dienst- 
xind/oder diensteteihiehmerabhangig sein oder unabhangig davon von 
samdichen IN-Nachrichten genutzt werden. Die Prozesse sind in einer oder 
10 mehreren Inkamationen auf alien bzw. ausgewahlten Prozessoren eines SCP 
implementiert. 

Die Abarbeitung einer IN-Nachricht im SCP erfolgt in der Kegel nach 
folgendem Schema, reahsiert durch Aufinif einer vorbestimmten Kette von 
15 Einzelprozessen: 

Eine Nachdcht vom SSP wird empfangen imd an den SCP-Rechner 
weitergeleitet, Der SCP-Rechner empfangt die Nachricht, Speicher wird vom 
zur Verfiigung gesteUt und die Nachricht wird auf ihren Giiltigkeitsbereich 
20 uberpriift. Der Kontext zur Anrufbehandlimg wird erstellt. Ein Routingtree 
wird aus dem Arbeitsspeicher oder von der Festplatte geladen_ Aus dem 
Routingtree wird die anzuwahlende Rufioiummer ermittelt. Der Kontext zum 
Anruf wird gespeichert und eine Antwort an den SSP ersteUt. Die Antwort 
wird als neue IN-Nachricht an den SSP gesendet. 

25 

AUe zur Verarbeitung eines IN-Ru£s benotigten Prozesse werden nur auf 
einen Prozessor angestoBen, wobei der vorhergehende ProzeB terminiert sein 
muB, bevor der nachste ProzeB angestoBen werden kann. 

30 Die Verbindungsende-Behandlung nach Auslosung der Verbindung von der 
Vermittlungsstelle zum SSP durch den Anrufer wird analog zur oben 
dargestellten Verbindungsaufbaubehandlimg durch eine entsprechende 
ProzeBkette abgearbeitet. 

35 Die Abarbeitung einer IN-Nachricht im STP/SRP erfolgt ebenfalls durch 
Abarbeitung einer vorbestimmten Kette aufeinanderfolgender Prozesse, 



Technische Aufgabe: 
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Bei Messungen an existierenden IN-Netzwerken, insbesondere an deren 
zentraler Komponente SCP, wurden hohe mittlere Bearbeitungszeiten 
beobachtet. Dieses fiihrt zu inakzeptabel langen Verbindungsaxifbauzeiten bei 
5 hoher Auslastimg des Systems durch IN-Verkehr, insbesondere zu 
Spitzenzeiten 

des Dienstes Televotum, aber auch durch andere Einfliisse. Die Analyse von 
Schwachstellen des QJ-Netzes, die zu solchen erhohten Antwortzeiten fuhren, 
ist jedoch problematdsch, da die MeBwerte jeweils nur statistische Daten sind 

10 und eine Messung nicht in jedem Stadium der Nadmchtenbearbeitung 
vorgenommen werden kann. Weiterhin besteht auch eisx grundsatzliches 
Problem bei der Messung am realen IN dergestalt, daB aUe realen 
Detailmessungen die Performance des zu untersuchenden Systems durch 
Aktivierung zusatzlicher MeJBprozesse, die nicht zur regularen XN-CaU- 

15 Behandlung gehoren, beeinflussen. 

Ein weiteres Problem ergibt sich bei der Implementierung neuer 
Komponenten in ein bestehendes IN. Das IN befindet sich zu jedem Zeitpunkt 
im Betriebszustand, wobei eine Parameteranderung an diesem komplexen 
20 System ohne Gefahrdung der Betriebssicherheit nicht mogjich ist. Es ist 
weiterhin gegenwartig nicht feststeUbar, ob beispielsweise Prozessoren mit 
einer bestimmten technischen Spezifikation tatsachlich die vom Hersteller 
zugesicherten Leistungen bringen. 

25 Neben der Notwendigkeit, SchwachsteRen schon bestehender InteUigenter 
Netze zu analysieren, besteht ein Bediirfiais dahingehend, auch noch nicht 
reaUsierte Netakonfigurationen bereits im Planungsstadium zu testen, um 
innerhalb gegebener Randbedingungen die Konfiguration mit der 
bestmoghchen Performance zu ermittehi. Es stellt sich beispielsweise die 

30 Frage, welche Leistungsfahigkeit der SCP-Rechner bzw. dessen 

Einzdprozessoren haben miissen oder welche Kapazitaten ggf. in welcher 
Form fiir die einzehien Dienste bereitgestellt werden miissen. Weiterhin stellt 
sich die Frage, ob und wie mogiicherweise durch eine geanderte 
ProzeBverwaltung innerhalb der Prozessoren des IN eine bessere Performance 

35 erzielbar ist. Ein weiteres kritisches Element beim Betrieb eines Intelligenten 
Netzes ist auch der Uberlastabwehrschutz, der das System mo^chst nahe an 
seiner Leistungsgrenze stabilisieren soU. Die Ermittlung entsprechender 
tiberlastabwehrparameter ist in der Praxis nur schwer moglich, so daU das 
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Bedurfeus besteht, die optimalen Einstellungen der Uberlastabwehr in 
Abhangigkeit von sonstigen Netzkonfigurationen unabhangig vom 
Netzbetrieb zu ermitteln und auf das reale Netz zu iibertragen, 

5 Der Erfindung liegt daher die Aufgabe zugrunde, ein Werkzeug zur 

Ermitdung der Performance eines Kommunikationsnetzes mit IN-Stniktur 
zur Verfiigung 

zu stellen. Dabei soli der Benutzer die Netzkonfiguration sowie die Art der 
Anrufbehandlung innerhalb der Netzkomponenten in weiten Grenzen 

10 angeben und verandem konnen, die Simidation soU also unabhangig von der 
gewahlten IN-Platform sein. Es soUen statistische Daten zur Performance des 
Netzes erzeugt werden, welche einen Vergleich an mit realen IN- 
Komponenten gemessenen Daten erlauben, weiterhin sollen jedoch auch 
solche Daten zur Verfiigung gesteUt werden, auf welche bei realen Netzen 

15 keine Zugrifemogtichkeiten bestehen, so etwa rufspezifische ProtokoUierung 
der Bearbeitungszeiten beim Durchlauf des Intelligenten Netzes. 

Offenbarung der Erfindung und deren Vorteile: 

20 Die Losung der Aufgabe besteht erfindungsgemaB bei einem Simulator zur 
Simulation der Performance eines Intelhgenten Netzwerks OOSf). der folgende 
Komponenten aufweist: 

1. Ein Modul zur Simulation behebiger IN-typischer Ereignisfolgen 
(Verkehrssimulator) nach den Regebi der Verkehrstheorie; 
25 2. einem Modul zur ereignisorientierten Simulation des Service Control Poiat 
(SCP-Simulator) imter Verwendung von ProzeBmodellen; 

3. Mittel zur Dateniibergabe zwischen den Modulen; 

4. Mittel zur Eingabe und Speichenmg der Netzkonfiguration, 
Kommunikationsdienstespezifikation und sonstigen SimulatiLonsparametem 

30 sowie deren LFbergabe an die entsprechenden Module; 

5. Mittel zur Ausgabe und/oder Speicherung der simulierten Daten. 

Da die Ursachen fiir die Performancedefizite des InteULgenten Netzes 
aufgrund dessen zentrahstischer Struktur haufig im zentralen SCP zu suchen 
35 sind, bildet die ModeDierung des SCP des Kemstucks des Simulators. Mittels 
Warteschlangenmodellen/ProzeBmodellen ist eine detaiUierte ModeDierung 
der Softwarestruktur des SCP realisierbar. Ein weiteres Modul, der 
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Verkehrssmiulator, wixd im IN-Simulator benotigt, um IN-spezifische Last zu 
generieren und realistischen Input fiir den SCP-Simulator zu erzeugen. 

Der Simulator ist im Kern durch ein Computerprogramm realisiert. Dieses 
5 Programm greift beim Start oder wahrend der Simulation auf Dateien zu, in 
welchen Parameter zur Konfiguration des Netzes bzw. der Netzkomponenten, 
zur Spezifikation der Kommunikationsdienste, d.h. Art und Ablauf der 
Anrufbehandlung, sowie sonstige den Simulationsablauf betreffende 
Parameter, 

10 Z.B. Angaben iiber das Verkehrsaufkommen, gespeichert sind. Diese Dateien 
sind vom Benutzer in bekannter Weise beschreibbar und veranderbar. 
Vorzugsweise erfolgt die Eingabe der Simulationsparameter unter 
Verwendxmg von Bildschirm und Tastatur eines Computers. Die 
Simulationsparameter werden gespeichert und konnen vor Durchlauf einer 

15 neuen Simulation einzeln oder in ihrer Gesamtheit verandert werden, so daB 
gezielt der EinfluB einzelner Parameter auf die simulierte IN-Performance zu 
analysieren ist. 

Die verwendete Simulationsart entspricht der sogenannten 
20 ereignisgesteuerten Simulation. Fiir spezieUe Zeitpunkte, werden IN- 
spezL&sche Ereignisse generiert, die zur Bearbeitung die einzelnen 
Komponenten des Simulators durchlaufen. Die in den e in z el n en 
Simulationsmodulen, g^, auch in Unterkomponenten der Simulationsmodule, 
anfaHenden Bearbeitungszeiten werden mitprotokoULert. 

25 

Vorzugsweise weist der IN-Simulator zusatzHch zu den Basiskomponenten 
SCP-Simulator und Verkehrssimulator era Modul zur ereignisorientierten 
Simulation des Zeichengabesystems Nr. 7 auf. Dieser SS7-Simulator arbeitet 
auf der Basis von WarteschlangenmodeUen, soweit FtrnktionaKtaten in das 

30 SS7 integrierter Prozessoren nachgebUdet werden soUen, und/oder pragt einer 
Nachricht lediglich eine konstante Verzogerungszeit auf, welche die endliche 
Laufeeit in den Zeichengabekanalen zwischen SSP \md SCP beriicksichtigt. 
Die innerhalb des SS7-Simulators zu simuKerenden Komponenten sind die 
Prozessoren/ProzeBketten in der SSP-Ebene, der STP/SEP-Ebene und je nach 

35 Netzkonfiguration der SCP-Ebene, z.B, ein SCP-Eingangsprozessor (FRONT 
END SYSTEM), welcher die SchnittsteUe des SCP zum Zeichengabesystem 
bildet. 
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In edner weiteren vorteilhafteii Ausfuhrung der Erfindung ist em Modul zur 
Simulation von tTberlastabwelirmechanismen vorgesehen. Dieser 
Uberlastabwehr-Simulator modifiziert die Anzahl der von wenigstens einem 
der iibrigen Simulisationsmodulen verarbeiteten Ereignisse in Abhangigkeit 
5 von der Belastung eines oder mehrerer Simulationsmodnle, z.B- in 
Abhanigkeit von der Warteschlangenlange, und/oder von 
benutzerdefinierbaren Parametem. Die benutzerdefinierbaren Parameter sind 
beispielsweise Belastungsgrenzen, bei deren Uberschreitung die 
tiberlastabwehr aktiviert wird. Anstatt fest definierter Grenzen kann auch 

10 eine "imscharfe" Entscheidung vorgesehen sein, z.B. mittels einer Fuzzy- 
Logik. Realen Verhaltnissen am ehesten entsprechend ist ein 
Uberlastabwehr-Simidator, wekher seine Steuerungsparameter vom SCP- 
Simtdator erhalt, auf den Verkehrssimulator zugreift und die Menge der vom 
VerkehrsSimtdator erzeugten oder weitergegebenen IN-Ereignisse in 

15 Abhangigkeit von den Steuerungsparametem reguhert. Bei Eingreifen der 
tiberlastabwehr wird ein vom VerkehrssimiQator zimachst erzeugter Anruf 
mit einer gewissen Wahrscheinlichkeit nicht in ein IN- Ereignis, das einer 
Anfrage des SSP an den SCP entspricht, umgewandelt, also nicht an die 
weiteren Simulationsmodnle weitergegeben. In der Reahtat entspricht dies 

20 einem vom SSP abgewiesenen Anruf. 

Vorzugsweise bildet der Uberlastabwehr-Simulator den Mechanismus des 
Automatic Call Gapping (ACG) nach. Dabei werden innerhalb eines 
bestimmten Zeitintervalls samtliche iiber eine bestimmte Anzahl 
25 hinausgehenden Anrufe/Ereignisse abgewiesen. 

Die Module Verkehrssimulator, SCP-Simulator sowie gegebenenfalls SS7- 
Simulator und Ubedastabwehrsimulator steUen eigenstandige Simulatoren 
der entsprechenden Netzkomponenten dar. Intern sind ihre Funktionen 
30 entweder uber Dateien yerkniipft (Datei-Modus) oder vorzugsweise iiber ein 
Organisationsprogramm integriert (Online-Modus), das die Abarbeitung der 
einzekien EN-Ereignisse iiber alle Komponenten des IN-Simtdators hinweg 
gewahrleistet. 

35 Im Datei-Modus erfolgt die Kommunikation zwischen den 

Simulationsmodulen in Form von Schreib- bzw. Lesezugriffen auf Dateien, in 
denen Daten bezii^ch der Konfigxuration des Netzes bzw, der zu 



wo 99/48306 



PCT/EP99/01141 



12 

simulierenden Netzkomponenten sowie gg£ die von einem der 
Simulationsmodule erzeugten Daten hinterlegt sini 

Urn eine voUstandige Simulation des Netzes durchzufiiliren, miissten die 
5 Teilsiinulationen nacheinander aufgerufen werden. Ein Simulationslaiif 
begiiint mit der Generienmg des Verkehrsaufkonunens am IN durch den 
Verkehrs-Simidators. Die generierten Nachrichten (PROVIDE 
INSTRUCTION mit ihrer Erzeugungszeit tl werden EVENT oder CALL END) 
in einer ersten Ubergabedatei gespeichert und von dem anschliefiend 
10 aufeurufenden Simulationsmodtd eingelesen. Es ist weiterhin zu jeder 

Nachricht eine Aaruf-IdentLfikationsnummer gespeichert, die die Zuordnimg 
mehrerer Nachrichten zu einem Anruf und damit letztendlich die Bestimmung 
von rufspezifischen Antwortzeiten erlaubt. 

In der einfachsten Version des Simxdators ist dieses zweite Simulationsmodnl 
15 der SCP-Simulator. Bei Beriicksichtigung des SS7 wird die erste Datei 
hingegen an den SS7- Simulator iibergeben- In diesem Fall werden die 
Nachrichten nach dem Dnrchlaufen des SS7-Simulators, erganzt urn den SS7- 
Ausgangszeitpunkt t2, in eine zweite Ubergabedatei geschrieben, auf welche 
der SCP-Simvdator zugreifl. Der SCP-Simulator erzeugt zu jedem in der ihm 
20 iibergebenen Datei vorhandenen Eintrag eine Nachricht CREATE-JOIN oder 
CALL END und schreibt diese mit der Ausgangszeit t3 in eine dritte Datei 
Vor der Ankunft der Nachricht in SSP wird ggf. nochmals der SS7-Simulator 
durchlaufen, wobei der SS7- Ausgangszeitpunkt t4 protokoDiert wird. 

25 Aus den Ubergabedateien der Simulationsmodule konnen durch 

Differenzbildung der protokoDierten Zeitmarken die Verzogerungszeiten in 
den einzehien Netzkomponenten sowie im gesamten Netz ermittelt werden. 

Da durch den sequentieUen Betrieb der Teilsimulationen jede Form von 
30 Riickkopplungen zwischen den Netzkomponenten ausgeschaltet wird, miissen 
mehrere Durchlaufe des oben beschriebenen Vorganges erfolgen, um einen 
eingeschwungenen Zustand zu erhalten die FunktionaKtaten des realen 
Netzes weitgehend nachzubilden. 

35 Der Dateibetrieb eignet sich sehr gut, um das Verhalten einzelner 
Netzkomponenten getrennt vom Netz, also riickkopplungsfrei, zu 
untersuchen. Das Verhalten der einzelnen Komponenten laBt sich z.B. durch 
Modifikation der entsprechenden Simulationsparameter schnell und direkt 
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ermitteln. Dabei sind einzelne IN-Komponenten getxennt modifizierbar xind 
analysierbar. Der Dateamodus gestattet zudem, einzelne EVENTS zwischen 
den Komponenten leicht zu verfolgen. Das stationare Verhalten des 
Gesamtsystems laBt sich jedoch im Dateimodus nur iterativ mit geeigneten 
5 Anfangsbedingungen ermitteln. 

Im Online-Modus sorgt ein Organisationsprogramm dafiir, daB die 
Teilsimulationen quasiparallel ablaufen. Damit ist der Simulator imstande, 
das Netz als Ganzes zu simulieren und dabei insbesondere auch 
10 Riickkopplungen zwischen den Komponenten urunittelbar zu berucksichtigen. 
Die Umsetzung der in der ReaUtat parallel ablaufenden Bearbeitung der 
Nachrichten in den Netzkomponenten in eine sequentieUe bzw. quasiparallele 
Bearbeitung der IN-Ereignisse in den Simulationsmodulen wird mit Hilfe von 
Ereigniskalendem 

15 realisiert, Ein Ereigniskalender ist eine liste aller von einem Element, z.B 
dem Simulator, einem Simulationsmodul oder einer Teilkomponente eines 
Moduls, abzuarbeitender Ereignisse, z,B. EN-Nachrichten oder Einzelprozesse, 
die in chronologisclier Rethenfolge in diese Liste eingetragen sind. Mt hilfe 
der Ereigniskalender bestimmt der Online-Simulator, welches Ereignis als 

20 nachstes zu bearbeiten ist (Ereignisorientierte Simulation). Der 

Startzeitpunkt des nachsten Ereignisses ergibt sich dabei additiv aus dem 
Startzeitpunkt und der Dauer des vorhergehenden Ereignisses. Eine zentrale 
Rolle bei der ReaKsierung des quasiparaHelen Betriebs der 
Simulationsmodule spielt der globale Ereigniskalender, der die von der 

25 Gesamtheit der Simulationsmodule abzuarbeitenden Ereignisse in 

chronologischer Reihenfolge enthalt. Anhand des globalen Ereigniskalenders 
bestimmt der Simulator, welche Teilsimulation zu welchem 
Simtdationszeitpunkt aufcurufen ist. Neben dem globalen Ereigniskalender 
existieren weiterhin lokale Ereigniskalender, die von den Simulationsmodulen 

30 gefuhrt werden. In den globalen Ereigniskalender sind Ereignisse folgender 
Ereignisgruppen eingetragen: 

Interne Ereignisse: Interne Ereignisse sind Verweise auf die lokalen Kalender 
der entsprechenden Simulationsmodule. Sie betrefiEen das Weiterschalten 
35 eines Simulationsmoduls um einen einzelnen Simulationsschritt. 

Exteme Ereignisse: Exteme Ereignisse reprasentieren die Eingabe einer IN- 
Nachricht in eine Teilsimulation, sie stehen fur Nachrichten die zwischen den 
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Simulatioiiskomponenteii verschickt werden xmd der Kommunikation der 
Simulationskomponenten untereinander dienen. 

Rufunabhangige Ereigrdsse: In einer Weiterbildung der Erfindung werden 
5 auch solche Ereignisse in dem globalen Kalender eingetragen, die 
xmabhanigig von IN-Ereignissen sind nnd z,B. zur Simulation der 
Betriebssysteme in den Teilkomponenten gehoren. 

Alle Ereignisse veranlassen in der Kegel das jeweilige Simulationsmodul znr 
10 Generierung eines Folgeereignisses, das wiederum in den globalen und unter 
Umstanden auch in den lokalen Ereigniskalender eingetragen wird. Einige 
Ereignisse veranlassen nach ihrer Abarbeitung eine ProtokolKerung, anhand 
derer nachvoUzogen werden kann, wie schnell eine Nachricht vom jeweiligen 
Silnulationsmodid bearbeitet wurde. 

15 

Die Funktionalitat des IN-Simulators ist fiir den Anwender vorzugsweise iiber 
eine Benutzeroberflache zuganglich, Diese Oberflache ubeminunt die 
Verwaltung einer oder mehrerer Simulationen, indem sie Eingabemasken zur 
Eingabe der Simtdationsparameter der einzelnen Simidationsinodule 

20 bereitsteUt, die eingegebenen Daten in entsprechenden Dateien ablegt und 
simulationsbezogen speichert. Die Generation einer neuen Simulation wird 
mittels Kopieren imd Modifizieren ausgewahlter Parameter durch den 
Benutzer ermoglicht. Die Benutzeroberflache beinhaltet eine weitgehend 
selbstandige Dateiverwaltung des zu jeder Simulation gehorenden Systems 

25 von Konfigurations- und Ergebnisdateien. Der Benutzer hat die Mo^chkeit, 
sich samtliche simuHerten Daten anzeigen zu lassen. Die vom Benutzer 
ausgewahlten "MeBgroBen", zJB. Auslastung der SCP, Warteschlangenlange 
im SCP, Verkehrsaufkommen im IN. werden mit Hilfe eines 
Grafiiprogrammes aufbereitet und sind als Grafik auf dem Bildschirm eines 

30 Computers darstellbar, Vorzugsweise konnen die Simulationsergebnisse 

sowohl einer Simidation als auch unterschiedlicher Simulationen gemeinsam 
auf einem Bildschirm dargestellt werden. Weiterhin ist vorzugsweise iiber 
Datedfilter die Erzeugung von Ausgabefiles zur Weiterverarbeitung in anderen 
Programmen mogtich. 

35 

Kurzbeschreibung der Zeichnung wobei zeigen: 

Figur 1 Die Topologie eines InteUigenten Netzes 
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Figuren 2 und 3 Die Struktur eines erfindungsgemafien, im Datei- Modus 
betriebenen Simulators 





Figur4 


Die Struktur eines erfindungsgemaBen, im Datei- sowie 




im Online-Modus betreibbaren Simidators 


5 


Figur 5 


Prinzipieller Aufbau eines IN-Simulators 




Figure 


Fnn Beispiel fiir Konfigurationsparameter des 






Verkehrs-Simulators 




Figur 7 


Prinzipieller Simulationsablauf im Datei-Modus 




Figur 8 


Prinzipieller Simulationsablauf im Online-Modus 


10 


Figur 9 


Schematisch die Abarbeitung eines globalen intemen 






Ereignisses aus der Sicht der Online-Simulation 




Figur 10 


Prinzip der SCP-Simulation 




Figur 11 


Beispiel fur Konfigurationsparameter des SCP- 






Simulators 
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Figur 12, 13 


Ein der SCP-Simulation zugrundeliegendes Modell der 






ProzeBverwaltung einer CPU 




Figur 14 


Ein schematisches, objektorientiertes ModeU eines SCP- 






Simulators 




Figur 15 


Anordnung der SS7-Schichten 


20 


Figur 16 


Modellierung der MTP3 Ebene des SRP 




Figur 17 


Modellierung der TCAP-Schicht des SS7 




Figur 18 


Beispiel for Konfigurationsparameter des SS7-Simulators 




Figur 19 


die Implementierung des Uberlastabwehr-Simtdators in 






den IN-Simulator im Online-Modus 


25 


Figur 20 


die Implementierung des Uberlastabwekr- Simulators in 



den IN-Simulator im Datei-Modus 

Figuren 21, 22, 23 Beispiele fiir mit dem IN-Simulator ermittelte 

Simulationsdaten. 

30 Wege zur Ausfuhrung der Erfindung: 

Figur 1 zeigt die Topologie eines LiteUigenten Netzes zur Darstellung des 
Simidationskonzeptes, Ein InteUigentes Netz weist im wesentlichen drei 
logische Komponenten auf, den Service Control Point (SCP) 109, den Service 
35 Switching Point (SSP) 102 sowie den Signal Transfer Point bzw. Signal Relay 
Point (STP bzw, SEP) 103. Die SSP-Ebene nimmmt 

Signalisierungsanforderungen der als extern betrachteten Kundengerate liber 
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eine der Vermittliingsstellen 101 des Telefonnetzes entgegen und betreibt den 
Verbindungsaiifbau fiir solche IN-spezifischen Verbindungen. 

Die SCP-Ebene enthalt Prozeduren und Datenbanken znr Rufbewertung nnd 
5 zum Verbindungsmanagement, Diese Informationen dienen dazu, den Weg fiir 
eine Verbindung durch das Telefonnetz zu finden. Der SCP bzw. SEP 
ubeminunt Vermittliingsftinktionen zwiscben SCPs und SSPs. Die 
Kommunikation zwischen den Komponenten SSP, SCP und STP/SRP folgt 
iiber das Zeichengabesystem Nr. 7 (SS7). Dazu bestehen in der Kegel eine 
10 Viekahl von Zeichengabekanalen 106, 107, 108 zwischen STP/SRP und SSP 
bzw, STP. 

Prinzipien konnen die drei logischen Komponenten SSP, SCP und STP/SRP in 
einem physikalischen Gerat integriert sein, z.B_ in einer Vermittlungsstelle. 

15 Der Regelfall ist allerdings die in Pigur 1 dargestellte psrramidenartige 

Struktur des InteUigenten Netzes mit einem zentralen SCP 109 einer Vielzalil 
von davon beabstandeten SSPs 102 sowie einigen STR/SRP 103 als 
Nachrichtenknoten im SS7-System. Zwischen den Vennitdungsstellen des 
Telefonnetzes und des SSPs bestehen physikalische Nutzkanale 105, iiber 

20 welche Telefonverbindungen aufgebaut werden konnen. Ein Anruf mit eiaer 
IN-spezifischen Rufiitunmer wird zunachst grundsatziich an einen SSP 
vermittdt, wekher nach Erhalt der Weiterbehandlungsinformation von SCP 
die Verbindimg an das jeweilLge Ziel weitervermittelt. Der SSP stellt somit die 
Schnittstelle zwischen dem Telefonnetz und dem InteUigenten Netz dar. SSP- 

25 FunktionaHtaten konnen auch direkt in eine Vermittlxmgsstelle integriert 
sein. 

Im Rahmen der IN-Simulation wird der von den SSPs in das InteUigente Netz 
gelangende IN-Verkehr mit dem Verkehrssimulator simuUert, die Fimktion 

30 des SCP wrrd mit dem SCP-Simulator modeUiert, der SS7-Simulator 
modelliert die Funktionen der SSPs, der STPs/SRPs, der SCP- 
Eingangsprozessoren 104 sowie der Verbindungsleitungen zwischen diesen 
Komponenten. Der Anwender des Simulators hat die Moglichkeit, im Rahmen 
der Eingaben zur Netzkonfiguration die Netztopologie firei zu wahlen \md so 

35 die Struktur des simuUerten Netzes beliebigen Vorgaben anzupassen. Zu den 
benutzerdefinierbaren Simulationsparametem gehoren die Anzahl der SSPs 
102, die Anzahl der STPs/SRPs 103, die Anzahl der SCP-Eingangsprozessoren 
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104 die Anzahl der Zeichenkanale zwischen einem STP/SRP xmd einem SCP 
bzw. einem SSP, ggf. auch die Anzahl der SCPs. 

Figur 2 zeigt die Struktur eines erfindungsgemaBen, im Datei-Modus 
5 betxiebenen IN-Simulators den Simulationsmodulen Verkehrs-Sunidator 201 
und SCP-Simulator 202. Der Verkehrs-Simulator 201 generiert gemaB den 
Benutzerangaben, die in Eingabedateien 208, 209, 210, 211, 212 hintedegt 
sini unter Benicksichtigung der gg£ in der Ubergabedatei 204 gespeicherten 
Daten ein IN-spezifisches Verkehrsaufkommen, ih. eine Folge von 

10 Ereignissen, welche EN-Nachrichten eines oder mehrerer SSPs an den SCP 
reprasentieren. Die Eingabendateien 208 bis 212 sindfiir den Anwender 
vorzugsweise uber eine gemeinsame Benutzeroberflache zuganglich und 
werden vom Verkehrssimulator 201 beim SimuIationsbegiQn eingelesen. Die 
Eingabedateien 208 bis 212 enthalten Parameter, welche jeweils 

15 unterschiedliche Aspekte der Simulation betreffen, z.B. die Netzkonfiguration 
im Bereich der Schnittstelle zwischen IN und Telefonnetz betreffend (Anzahl 
SSP). die intemen Eiostellxuigen eines SSP betreffend (Anzahl Ansageplatze 
pro Dienst, Zeit bis zum Timeout, Anzahl Leitungsverbindungen), das weitere 
Schicksal eines Anrufs betreffende Wahrscheudichkeiten (mitdere Gesprachs- 

20 imd/oder Ansagendauer, maximale Ansagendauer, 

Umlenkwahrscheinlichkeit), Angaben zur mittleren Anzahl Anrufe pro 
Zeiteinheit und Dienst fur eines oder mehrere aufeinanderfolgende 
ZeitintervaUe. Es versteht sich von selbst, daB die Anzahl der Eingabedateien 
208 bis 212 wiUkiirlich ist und beispielsweise samtliche Benutzerangaben, 

25 auch andere Simulationsmodule betreffend, in einer belLebigen Anzahl 
Dateien, auch einer einzigen, gespeichert sein konnen, 

Im hier dargestellten Beispiel weist der SCP-Simulator 202 eine SCP- 
Eingabedatei 207 auf, in welcher Benutzerangaben bezii^ch der SCP- 
30 Konfiguration gespeichert sind und die der SCP-Simxdator 202 bei 
Simulationsbegtnn einhest. 

Im Dateimodus werden die Module Verkehrssimulator 201 xmd SCP- 
Simxdator 202 nacheinander betrieben. Die vom Verkehrssimulator erzeugte 
35 Ereignisfolge wird in eine erste Ubergabedatei 203 geschrieben, welche die 

nunmehr vom SCP-Simulator 202 abzuarbeitenden Ereignisfolgen enthalt. Im 
darauffolgenden Schritt liest der SCP-Simulator diese Ubergabedatei 203 ein 
imd arbeitet die darin abgespeicherten Ereignisse ah. Die abgearbeiteten 
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Ereignisse werden vom SCP-Simulator 202 in eine zweite Ubergabedatei 204 
eingetragen. Diese wird bei laufender Simulatioii erneut dem Verkehrs- 
Simulator 201 ubergeben, kann aber wie auch die erste Ubergabedatei 203 
dixekt der Auswertung zugefuhrt werden. 

5 

Die tibergabedateien stellen inhaltUch die Ereigniskalender des jeweiligen 
empfangenden Moduls dar. In den tibergabedateien 203, 204 sind die vom 
Verkehrs-Simulator 201 bzw. vom SCP-Simnlator 202 erzeugten Daten als 
Datensatz gespeichert, der jeweils mindestens eine Zeitmarke, die die 

10 Erzeugungszeit der entsprechenden Nachricht am Verkehrs-Simulator bzw. 
am SCP-Simulator angibt, xmd eine IdentifUcationsnummer, welche die 
Zuordnung zweier oder mehrerer Nadirichten als zu einem Anruf gehorend 
erlaubt, enthalt. Die Differenz beider Zeitmarken gibt die Bearbeitungszeit 
einer Nachricht im SCP an. Somit laBt sich mit dem in Figur 2 s k iz z ierten 

15 Simulator die Reaktion des SCP auf eia gegebenes Verkehrsaufkommen 
direkt simuHeren. Das Zeichengabesystem Nr. 7 wird dabei nicht 
beiriicksichtigt. 

Die Simulationsmodule 201, 202 legen weiterhin statistische Daten, z.B. 
20 beziighch der Prozessorauslastung im SCP, der Warteschlangenlange im SCP 
oder der Leitungsauslastung vom und zum SSP, in Ausgabedateien 205, 206 
ab. Die darin aufeezeichneten Daten stehen ebe nf a l Ls zur weiteren 
Auswertung der Simulationsergebnisse zur Verfugung. 

25 Figur 3 zeigt die Struktur eines erfindungsgemaBen, im Datei-Modus 

betiiebenen Simulators mit den Simulationsmodulen Verkehrssimulator 301, 
SS7-Simulator 303 und SCP-Simulator 302. Gegentiber dem Simulator aus 
Figur 2 ist der in Figur 3 dargestellte Simulator lediglich um das Modul SS7- 
Simulator 303 erweitert. Dies hat zur Folge, dafl zwischen den Modulen bei 

30 der sequentiellen Abarbeitimg der Teilsimulationen nunmehr vier 
tibergabedateien 304, 305, 306, 307 iibergeben werden. 

Die Simulation des Intelligenten Netzes beginnt wie im oben beschiiebenen 
Fall mit der Generierung eines IN-spezrfischen Verkerhsaufkommens. Der 
35 Verkehrs-Simulator 301 liest dazu die Eiugabedateien 312 bis 316 ein, welche 
den Dateien 208 bis 212 aus Figur 2 entsprechen faUs vorhanden, wird auch 
die tJbergabedatei 307 eingelesen. Die vom Verkehrs-Simulator 301 generierte 
Ereignisfolge wird in der ersten tJbergabedatei 304 abgespeichert. Dann wird 
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der SST-Simulator 303 aufgerufen. Dieser liest zunachst die SST-Eingabedatei 
317 ein, in welcher beispidsweise Daten beziigiich der Koiifiguration des SS7- 
Systems gespeidbert sind. Der SS7-Simulator 303 speichert die von ihm 
bearbeiteten Ereignisfolgen in einer zweiten Ubergabedatei 305, welche vom 
5 SCP-Simulator 302 bei dessen Aufruf eingelesen wird- Die vom SCP- 
Simulator 302 bearbeiteten Ereignisfolgen werden dann in einer 
Ubergabedatei 306 eingetragrai. Urn den Riicklauf der IN-Nachrichten vom 
SCP zum SSP zu simulieren, wird der SS7-Simulator 303 emeut aktiviert und 
verarbeitet die ia der diitten Ubergabedatei 306 gespeicherten Ereignisfolgen, 

10 wobei die Ergebnisse in der vierten tlbei^abedatei 307 abgelegt werden. Bei 
Bedarf wird nun emeut der Verkehrs-Simulator 301 aktiviert und der Zyklus 
SS7-Simulator. SCP-Simulator, SS7-Simulator emeut durchlaufen, um 
Riickkopplungen zwischen den Netzkomponenten zu simulieren. Die Iteration 
wird so lange durchgefalirt, bis die Anderungen der Verkehrsdaten in eiaer 

15 Oder mehrerer der Ubergabedateien 304 bis 307 (bzw. oben 203, 204) ein fiir 
den Benutzer akzeptables MaB unterschritten haben und somit das System 
einen eingeschwungenen Zustand erreicht hat. 

Statistikdaten beziigiich der einzelnen Simulationsmodule 301, 302, 303 
20 werden in Ausgabedateien 309, 308 bzw. 310 gesdmeben. Bezu^ich der SS7- 
Simulation sind dies beispielsweise Auslastung der SRP-Prozessoren oder die 
Anzahl der belegten Verbindungen von SRP zvun SCP bzw. zu den SSPs. 

Die iQ den tJbergabedateien hinterlegten Daten sind anrufspezifische 
25 Datensatze, die jeweils mindestens eine Zeitmaxke enthalten. Diese Zeitmarke 
ergibt sich aus der aktuellen Simulationszeit beim Erzeugen bzw. Abarbeiten 
der dazugehoiigen Nachricht in den entsprechenden Simulationsmodulen. 
Durch Differenzbildung lassen sich somit die Bearbeitungszeiten in den 
jeweiligen simulierten Netzkomponenten berechnen. 

30 

Figur 4 zeigt die Struktur eines erfindungsgemaBen, im Datei- sowie im 
Online-Modus betreibbaren Simulators. Der Simulator weist die bereits in 
Figur 3 dargestellten und beschriebenen Simulationsmodule Verkehrs- 
Simulator 401, SS7-Simulator 403 und SCP-Simulator 402 auf. Diese 
35 kommunizieren wie oben dargestellt, iiber Ubergabedateien 406, 407, 408, 
409. 
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Gegenuber dem Simulator aus Figur 3 enthalt der hier dargestellte Simulator 
zusatzKch eia Modul zur Simulation der Uberlastabwehr 404. Dieses reguliert 
die vom Verkehis-Simulator 401 generierten bzw. weitergegebenen 
Ereignisfolgen in Abhangigkeit bestimmter benutzerdefinierter Parameter, 
5 gespeicbert in Datei 424, sowie von der Belastung der iibrigen 
Simulationsmodule. 

Die Simulationsmodule 401. 402. 403, 404 sind dureh ein gemeinsames 
Oi^anisationsprogramm, den Online-Simulator 405, verknupft. Es ist 

10 weiterhin eine Benutzeroberflache 410 vorhanden. die mit alien 
Komponenten, also den Simulationsmodulen in direkter uni- oder 
bidirektionaler Verbindung steht AuBerdem bestehen zwischen 
Benutzeroberflache und den Simulationsmodulen indirekte Verbindungen 
uber Dateien 411 bis 414 (Eingabedateien fiir Verkehrs-Simulator 401), 415 

15 (SS7-Eingabedatei), 416 und 423 (SCP- Ein-/Ausgabedatei), 417 bis 420 

(Ausgabedateien des Online-Simulators 405), iiber welche sowohl die Module 
konfiguiiert als auch ermittelte Systemdaten ausgelesen werden konnen. Die 
gestrichelten Pfeile in Figur 4 symboUsieren, wie auch in den Figuren 2 und 
3, Dateioperationen, wahrend die durchgezogenen Pfeile eine direkte 

20 Kommunikation beschreiben, z.B. durch Verkniipfung iiber ein gemeinsames 
Organisationsprogramm. Ein Pfeil beginnt bei derjenigen Komponente, die 
Parameter oder Nachrichten an einen anderen Simulationsteil iibergibt. 

Der in Figur 4 dargestellte Simulator erlaubt sowohl den Datei-Betrieb mit 
25 sequentiellem Aufirufen der einzelnen Simulationsmodule als auch den 

Online-Betrieb, bei welchem die Simulationsmodule quasiparallel arbeiten. 

Die Benutzeroberflache steht jeweils mit dem Verkehrs- SS7- und. SCP- 
Simulator in Verbindung; die jeweilige Simulation wird von der 
30 Benutzeroberflache unter Ubergabe der entsprechenden 

Simulationsparameter gestartet. Im Dateimodus laufen Teilsysteme nach 
ihrem Aufruf als eigenstandige Programme unabhangig von der Oberflache 
und ohne Interaktionen ab. 

35 Die bidirektionale Verbindung zwischen Benutzeroberflache 410 und Onhne- 
Simulator 405 erlaubt einerseits den Simulationsstart mit entsprechender 
Parameteriibergabe und andererseits eine Riickgabe von "MeCdaten" zur 
grafischen Ausgabe wahrend der Laufeeit (Onhne-Modus). Weiterhin ist es 
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dem Benutzer mo^ch, den Simulationsablauf voriibergehend zu 
unterbrechen oder vorzeitig zu beenden. 

Die Simulationsmodule 401, 402, 403 und 404 sind programmiertechmsdi in 
5 den Online-Simulator 405 integriert, der den quasiparallelen Ablauf der 
TeUsimulationen durch das Versenden und Empfangen von Nachiichten, die 
im ^obalen Ereigniskalender verwaltet werden, steuert. Im Online-Betrieb 
finden somit samtliche Kommunikationsvorgange zwischen den Modulen 
Verkehxs-Simulator 401, SS7-Simulator 403 und SCP-Simulator 402 fiber den 
10 Online-Simulator 405 statt. Die t)bergabedateien 406 bis 409 werden im 

Online-Betrieb nicht direkt verwendet. Indirekt finden sie sich jedoch in den 
lokalen Ereigmskalendem wieder. 

Der Online-Simulator 405 veranlaOt die Eintragung von vorbestimmbaren 
15 ProtokoUgroBen, z.B. die oben besduiebenen Zeitmarken tl bis t4, die SCP- 
Auslastung, Daten zur Netzauslastung oder die Anzahl der belegten 
Leitungen, in Protokolldateien 417, 418, 419. 420. Die dort gespeicherten 
Daten sind ia bekannter Weise an der Benutzeroberflache ausgebbar und 
visualisierbar. 

20 

Da die Uberlastabwehr den in das IN gelangenden Verkehr durch 
Riickkopplungen reguliert, ist eine Simvdatiou von 

Ubedastabwehrmechanismen in den meisten Fallen nur im Online-Modus 
sinnvoll durchzufiihren. Das Uberlastabwehrmodul 404 weist daher beim in 
25 Figur 4 dargestellten Simulator keine direkte Verbindung zum SCP-Simulator 
402 auf, anhand dessen Belastung der Uberlastabwehr-Simulator 404 die 
Zahl der vom Verkehrs-Simulator 401 geneiierten Ereignisse reguliert. Eine 
Verbindung zwischen SCP-Simulator 402 und tJberlastabwehr-Simulator 404 
besteht lediglich im Online-Modxis indirekt iiber dem Online-Simulator 405. 

30 

Figur 5 zeigt den prinzipiellen Ablauf einer IN-Simulation aus dem 
Blickwinkel des Benutzers. Die Simulationsmodule selbst sind dabei nicht 
dargestellt, sondem werden im Rahmen der Blackbox 501 abgearbeitet. Dabei 
kann der Uberlastabwehr-Simulator 502 und/oder der SS7-Simulator 503 
35 jeweils ein- oder ausgeschaltet werden, in der Figur 5 durch Schalter 

symbohsiert. Weiterhin kann deir Benutzer zwischen Datei- und Online-Modus 
wahlen, ebenfalls symbolisiert durch einen Schalter. 
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Neben diesen, die Stxuktxir des Simulators betreffenden Einsteilimgen, hat 
der Benutzer nach dem Start des Simulators die Moglichkeit, die 
tatsachlichen Simulationsparameter, also die zu simuliereade 
Netzkonfiguration, das Verkehrsaufkommen etc, zu definieren. Bei einem 
5 Urstart werden samtliche Eingabedateien von den Simxdationsmodulen neu 
eingelesen. Dariiber binaus ist jedoch eine gezielte Veranderung eLnzehien 
Parameter zur Generierung einer neuen Simulation oder auch ein emeutes 
Durchlaufen einer alten Simulation mo^ch. Der Simulator 501 ermittdt 
dann aufgrund der zuvor bestimmten oder aufgerufenen 
10 Simulationsparameter die vorbestimmten Ausgangsdaten, z,B. Verkehr, CPU- 
Auslastung, Warteschlangenlange als Funktion der Simulationszeit, und 
schreibt diese in Dateien. Die Daten konnen nun auf dem Bildschirm 
dargestellt werden oder, auf Datentragem abgespeichert, einer weiteren 
Verarbeitimg zugefohrt werden, 

15 

Figur 6 zeigt ein Beispiel fur Konfigurationsparameter des Verkehrs- 
Simulators sowie beispieUiafl numerische Werte fiir diese. Die in der Tabelle 
der Figur 6 dargestellten Parameter lassen sich unterglLedem in 
dienstespezifische Parameter, die fiir samtliche zu simuUerenden Dienste 

20 separat einstellbar sind, Televotum-Parameter, die sich auf den Dienst 

Televotum beziehen, sowie aUgemeine Parameter, die fiir samtliche Dienste, 
also fiir alle vom Verkehrs-Grenerator erzeugten Anrufe, giiltig sind. Die 
dienstespezifischen Parameter sind fiir folgende IN-Dienste einstellbar: 
Freephone (FPH), Tde-Info-Service (TIS), UniverseUe Rufiiummer (UNU), 

25 den In-Dienst FPHL und Televotum (TVS). Fiir den Dienst Televotum sind 
nicht alle der fiir die librigen Dienste einstellbaren Parameters sinnvoll; diese 
sind daher in der entsprechenden Spalte mit einem X markiert. Weiterhin 
kann auch Telefonnormalverkehr (NVK) berucksichtigt werden, da auch nicht 
EN-speziJasche Anrufe bei bestimmten Netzkonfigurationen den SSP belasten 

30 imd damit zur Auslastung des IN beitragen konnen, Fiir den NVK ist ledighch 
die Angabe des ersten dienstespezifischen Parameters, mittlere 
Gesprachsdauer, sinnvoU, da die iibrigen Parameter die IN-Funktionen wie 
Schalten eines Anrufes auf eine Ansage, oder Umlenken eines Anrufes 
betrefifen. 

35 

Die dienstespezifischen Parameter sind die mittlere Gesrpachsdauer, mittlere 
Ansagendauer, maximale Ansagendauer, der Anzahl der Ansageplatze, wie 
Ansage und Umlenkwahrscheinlichkeit, sowie fiir die Wahrscheinlichkeit der 
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Umlenkung dxirch "Teilnehmer besetzt". Diese Parameter werden benotigt, 
urn zu jedem Simulationszeitpunkt die Wahrscheinlichkeit fur die 
Generierung eines Folgeereignisses zu bestimmen, also die 
Wahrscheinlichkeit fiir die Generienmg eines Ereignisses EVENT oder 
5 EVENT(CALL END). 

Die Televotnm-Parameter sind fiir jeden Televotmn-Dienstteilnehmer TVl, 
TV2 usw. separat angebbar. In dem hier gezeigten Beispiel sind ledighch zwei 
Dienstteilnehmer aktiv. Die einstellbaren Parameter sind: Zielwert SSPl bzw. 

10 SSP2, Anzahl Zielwerte bis Verbindmig, Startzeit, Endzeit, sowie Endzeit fiir 
Folgeanrufe. Der Parameter "Zielwert" gibt dabei die Anzahl der Televotum- 
Anrufe an, die beim angegebenen SSP eingehen miissen, damit eine Nachdcht 
zimi SCP generiert wird. 1st dieser Parameter auf den Wert 1 gesetzt, so 
handelt es sich xmi die Option Televotum ohne Vorzahlen, ist der Wert groBer 

15 als 1, so handelt es sich um Televotum mit Vorzahlen im SSP. Der folgende 
Parameter "Anzahl Zielwerte bis Verbindung" gibt an, ob und beim wievielten 
Anruf eine Verbindung zum Dienstteilnehmer aufgebaut wird. Da der Dienst 
Televotum in der Kegel in engen zeitlichen Grenzen angeboten wird, sind zu 
dem die Angaben der Start- bzw. Endzeit des Dienstes vorgesehen. Der 

20 Parameter "Endzeit fiir Folgeanrufe" gibt an, bis zu welchem Zeitpunkt 
verspatet eingehende TV-Anrufe noch auf eine informative, ggf- 
diensteteilnehmerspezifische Ansage gelenkt werden. Die Televotum- 
Parameter geben an, unter welchen Voraussetzungen ein vom Verkehrs- 
Generator zunachst generierter TV-Anruf ein IN-Erstereignis hervorruft. 

25 

Weiterhin sind folgende allgemeine Konfigurationsparameter einstellbar: 
Der Parameter ''Zeit bis Timeout" gibt an, nach welcher Zeit nach Senden 
einer IN-Nackricht an den SCP und ohne Erhalt einer Antwort vom SCP ein 
Anruf durch den SSP abgewiesen wird. Der Parameter "Zeitverzug fiir 

30 Umlenkung" gibt die Verzogerung bei einem Anruf-Rerouting an. Die 

Parameter "mitdere und maximale Ansagendauer "TV nicht aktiV"' sowie 
"Anzahl Ansageplatze" fiir diese Ansage geben an, wie ein auBerhalb der 
Zeiten, in denen der Dienst Televotum aktiv ist, ankommender TV-Anruf 
behandelt wird. Die Parameter "Anzahl Leitungen von bzw. zu den SSPs" 

35 betreffen die Konfiguration des Netzes im Bereich zwischen 

Vermittlimgsstelle und SSP. Weiterhin ist die Anzahl der Leitimgen fiir den 
Dienst Freephone vorgebbar. Der Parameter "mitUere Wartezeit des A- 
Teilnehmers" gibt an, nach welchem mittleren Zeitintervall der anrufende 
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Teilnehmer auflegt, wenn bis dahin aoch kein Verbindxmgsaufbau eifolgt ist. 
Die folgenden zwei Parameter geben an, mit welcher Wahrscheinlichkeit bei 
nicht erfolgreichem Verbindungsaufbau ein Folgeanruf folgt sowie mit welcher 
maximalen Anzahl Folgeanrufe generiert werden. 

5 

Um ein IN-spezL&sches kombiniertes Verkehrsaufkommen zu generieren, sind 
neben den oben dargestellten Parametem, die hauptsachlich die Generierung 
von IN-Folgeereignissen (EVENT) betrejBfen, weiter^ Parameter notig, die die 
Randbedingungen fiir die Generierung von entsprechenden IN- 

10 Erstereignissen (PROVIDE INSTRUCTION) festlegen. Es ist daher die 
Eingabe des mittleren Verkehrsaufkommens in Anzahl der Anrufe pro 
Zeiteinheit vorgesehen. Das mittlere Verkehrsaufkommen andert sich zu 
beliebigen benutzerdefinierbaren Zeitpunkten und bleibt dazwischen 
konstant. Damit konnen behebig geformte zeitliche Belastungskurven erzeugt 

15 werden, insbesondere auch solche Spitzen, wie sie bei sinngemaBer 
Dienstzuordnung fiir den Diensttelevotum typisch sind. Das mittlere 
Verkehrsaufkommen wird fiir jeden IN-Dienst (FPH, TIS, UNU. FPHL, TVl, 
TVn) und den regularen Telefonverkehr (NVK) eingegeben. Falls mehrere 
SSPs vorhanden sind, wird das Verkehrsaufkommen dienstespezifisch fiir 

20 jeden SSP separat eingegeben. Die Anzahl der SSP ist damit auch ein 
Parameter, welcher im Rahmen der Verkehrs-Simulation einstellbar ist. 

Beim Verkehrsaufkommen wird von einem stufenfdrmigen zeithchen Verlauf 
ausgegangen, wobei jede Stufe bzw, jedes ZeitintervaU vorzugsweise die 
25 gleiche zeitliche Lange hat. Die Anzahl der Intervalle sowie die Intervallange 
ist dabei vorgebbar. 

Nach den Regeln der Verkehrstheorie wird aufgrund der obenstehenden 
Angaben fiir jeden Simidationszeitpunkt bzw. fiir jedes 

30 Simulationszeitintervall die Wahrscheinlichkeit ermittelt, daB ein Anruf mit 
einer speziellen Dienste- bzw. Diensteteilnehmerkennung an einem SSP 
ankommt. Die Lange der Simulationszeitintervalle liegt dabei vorzugsweise 
wesenthch unterhalb der Lange der IntervaUe, fur die ein mittleres 
Verkehrsaufkommen von Benutzer vorgegeben wurde. Die Lange der 

35 Simulationsintervalle Uegt vorzugsweise im Bereich Nanosekunden, wahrend 
sich das Verkehrsaufkommen auf der Zeitskala von Sekunden, z.B. 10-100 s, 
andert. Die Lange des Simulationszeitintervalls ist vorzugsweise so zu 
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wahlen, daU maxiiual ein Anruf pro Intervall erzeugt wird und sich somit 
samtliche erzeugte Anrufe in chronologischer Folge auflisten lassen. 

Die jeweilige momentane Wahrscheinlichkeit wird unter An n ah m e einer 
5 gegebenen WahrscheinKchkeitsverteilung sowie der vorgegebenen 

momentanen Durchschiiitts-Verkehrsmeiige fiir den behandelten Dienst. 
Diensteteilnehmer bzw. SSP berechnet. Die verwendete 
Wahrscheinlichkeitsverteiliing ist vorzugsweise eine Poisson-Verteilung, da 
diese das statistische Eintreffen voneinander nnabhangiger Ereignisse 

10 beschreibt nnd somit die statistischen Flnktuationen des Telefonverkehrs am 
besten wiedergibt. Fiir jeden Dienst, Diensteteilneluner und/oder SSP wird 
somit eine zeititLche Folge von Ereignissen erzeugt, wobei die Anzahl der 
Anrufe pro Zeiteinheit statistisch um den zuvor vorgegebenen momentanen 
Mittelwert schwankt, Bei den Diensten FPH, TIS, UNU. FPHL sowie 

15 Televotum ohne Vorzahlung wird potentiell jeder generierte Anruf zu einem 
IN-spezifischen Ereignis, welches zur Auslastung des Intelligenten Netzes 
beitragt, und daher zur Simulation der Performance des IN, insbesondere des 
SCP, relevant ist. 

20 Die so generierten Erstereignisse, den IN-Naclmchten PROVIDE 

INSTRUCTION entsprechend, werden mit ibrer Erzeugungszeit tl in 
chronologischer Folge in die erste Ubergabedatei in den globalen 
Ereigniskalender bzw. im Datei-Modus eingetragen. Televotmn-Anrufe fiihren 
bei aktivierter Vorzahlung nur bei jedem n-ten Anruf zu einem IN- 

25 Erstereignis (PROVIDE INSTRUCTION). Dieses wird ebenfalls mit der 

Erzeugungszeit tl in den globalen Ereigniskalender bzw. in die Ubergabedatei 
aufgenommen. Die iibrigen Anrufe sowie Anrufe des regularen 
Telefonverkehrs belasten ledighch den SSP, fiihren aber nicht zur Erzeugung 
von IN-Ereignissen. 

30 

Weiterhin erzeugt der Verkehrs-Generator einem IN- Anruf bzw. Erstereignis 
zugeordnete Folgeereignisse unter Beriicksichtigung der in der 
Konfigurationsdatei eingegebenen WahrscheinHchkeiten, die das weitere 
Schicksal eines IN-Ereignisses betreflfen. Kommt z.B. die IN-Verbindung zu 
35 einem realen Teilnehmer bzw. die Schaltung auf einen Ansageplatz aufgrund 
der Verbindungsbehandlungsinformationen (CREATE- JOIN) vom SCP in der 
Simulation ordnungsgemaB zustande, so wird das Gesprach nach der 
angegebenen mittiLeren Gesprachs- bzw. Ansagendauer beendet, indem der 
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Verkehrsgenerator das Folgeereignis EVENT(CALL END) erzeugt und in die 
tibergabedatei bzw. in den globalen Ereigniskalender eintxagt. Kommt die IN- 
Verbindung mit dem vom SCP mitgeteilten realen Teilnehmer in der 
Simulation nicht zustande, was vom Verkehrs-Generator tmter 
5 Beriicksichtigung der dafiir angegebenen Wahrscheinlichkeiten ermittelt 
wird, erzeugt der Verkehrs-Generator als Folgeereignis die IN-Nachricht 
EVENT, mit welcher beispielsweise eine Rerouting-Information vom SCP 
angefordert wird. Anf diese Weise ist der Verkehrsgenerator imstande, IN- 
typische Ereignisfolgen zu erzeugen, die realen Verkehrsaufkommen im IN 
10 weitgehend entsprechen. 

Zu jedem IN-Ereignis werden folgende Parameter gespeichert: 
Die Identifikationsnummer des Anrufis, der Zeitpunkt tl. zu dem die 
Nadmcht vom SSP gesendet wird, die Identifikationsnummer der Nachricht, 
15 Z.B. 1 fiir PROVIDE INSTRUCTION, 2 fiir EVENT, 3 fur EVENT(CALL 

END), die Identifikationsniunmer des Dienstes, z.B. 3 fur TIS, 5 fiir UNU, 6 
fiir FPH, 10+j (J=0, 89) fur den j-ten Dienstteilnehmer des Dienstes TV 
sowie eine Identifikationsnummer des SSP. 

20 Weiterhin wird zur Beriicksichtigung der Global Title Translation im IN in 
einer vorteilhaffcen Ausgestaltung der Erfindung auch eine KennziBPer zum 
Global Title (GT) als Routing-Kriterium generiert und als Parameter des IN- 
Ereignisses gespeichert. Die GT-Klasse wird ebenfaUs iiber eine vorgegebene 
WahrscheinlichkeitsverteLlung generiert. Im STP/SRP-Simulator werden dann 

25 vorzugsweise GT-spezifische ProzeBketten angestoBen, welche die 
RoutingfunktionaHtaten der STP/SRP-Ebene, also beispielsweise die 
Vermittlxmg des Rufis an das Netz eines anderen Netzanbieters, simulieren. 

Weiterhin ist die Zuordnung der vom Verkehrssimulator generierten 
30 Ereignisse zu Nutz- und Lastklassen vorteilhaft. Anrufbezogene IN-Ereignisse 
sind einer Nutzklasse zugeordnet, wahrend beispielsweise Management- 
Verkehr zwischen den IN-Ebenen durch Ereignisse einer Lastklasse simxUiert 
werden kann. Zu jedem vom Verkehrssimulator generierten Ereignis wird 
eine entsprechende IQassenkennziffer erzeugt und gespeichert, die von den 
35 iibrigen Simulationsmodulen erkannt wird und ggf. die Weiterverarbeitung 
des Ereignisses mitbestimmt. 
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Im Online-Modus werden die Folgeereignisse vom Verkehrsgenerator 
wahrend des Simulationsbetriebs mit den gegebenen Wahrscheinlichlceiten 
erzeugt, nachdem das dazugehorige Erstereignis die Simulations-Module SCP- 
Simulator sowie ggf, SS7-Simulator durchlaufen hat, nachdem also ein der 
5 SCP-Nachricht CREATE- JOIN entsprechendes Ereignis vom SCP-Simulator 
erzeugt und, ggf. nach Durchlaufen des SS7-Simulators beim 
Verkehrssimulator zur Abarbeitung anliegt, Im Online-Betrieb werden somit 
Riickkopplungen zwischen den SimulationsmodidenL automatisch bei der 
Generierung IN-spezifischer Ereignisfolgen diirch den Verkehrs-Simulator 
10 beriicksichtigt- 

Im Dateimodus konnen derartige Ruckkopplungen wegen des sequentiellen 
Aufrufe der Simulationsmodule nur durch Iteration erreicht werden. Beim 
ersten Aufiruf des Verkehrs-Simidators werden daher die Erstereignisse in 

15 oben beschriebener Weise geneiiert, und fur die Folgeereignisse wird zunachst 
erne vorgegebene, beispielsweise zeitHch konstante SCP-Antwortzeit 
angenommen. Diese Antwortzeit wird beim emeuten Atrfiruf des Verkehrs- 
Simulators durch die Antwortzeiten korrigiert, die sich aus der vom SCP- 
Simulator bzw. SS7-Simulator an den Verkehrs-Simulator iibergebenen 

20 Ubergabedatei ergeben. Bei mehrmaHgem Durchlaufen des Simulators ergibt 
sich ein eingeschwungener Zustand, bei dem auch Wechselwirkungen 
zwischen den Modulen weitestgehend beriicksichtigt sini 

Im Online-Betrieb erfolgt die Generierung der IN-spezifischen Erstereignisse 
25 wahrend des Ablaufs der Gesamtsimulation, also zu jedem 

Simidationszeitpunkt, z.B, in ns-Abstanden, Dadurch kann auch ein 
Eingreifen der Uberlastabwehr bei momentaner Uberlast der iibrigen 
Simulationsmodtde simulLert werden und ein Anruf vor der Erzeugimg bzw. 
Weitergabe eines entsprechenden IN-Ereignisses abgewiesen werden. 

30 

Eine Folge der am SSP bzw. an den SSPs ankommenden Anrufe, die in der 
Regel etn IN-Ereignis nach sich ziehen, kann jedoch vor Simulationsbeginn 
nach den oben geschilderten verkehrstheoretischen Verfahren erzeugt und 
wahrend der Simulation abgearbeitet werden, d.h. als IN-Ereignis 
35 weitergegeben oder aufgrund der Uberlastabwehr fallengelassen werden. 

Aus dem generierten Verkehrsaufkommen kann fur jeden 
Simulationszeitpunkt die Auslastung der Zeichenkanale im Intelligenten Netz 



wo 99/48306 



PCT/EP99/01141 



28 

ermittelt werden. Aufgnmd der benutzerdefinierten Wahrscheinlichkeiten 
zum weiteren Schicksal des Anntfe (z.B. Gesprach oder Ansage bestimmter 
mittlerer Dauer) kann auch die Anzahl der belegten Sprechverbindungen za 
und von den SSPs und/oder die Anzahl der belegten Abnehmerleitungen fiir 
5 Teflnelimer am Dienst Freephone als Funktion der Zeit protokoUiert und 
ausgegeben werden, Weiterhin ist als Funktion der Simulationszeit 
ausgebbar, wieviele Anrufe in verschiedenen Stadien abgewiesen wurden, zJB. 
unmittelbar nach Erzeugung durch Uberlastabwehr, nach Ablauf des 
Timeouts bei Nichtreaktion des SCP oder wegen Belegung samtlicher 
10 Ansageplatze. 

Figur 7 zeigt den prinzipiellen Simidationsablauf im Dateimodus. Nach dem 
Start des Simulators werden die Eingabedateien der einzelnen 
Simulationsmodule eingelesen. Der Verkehrs-Simulator steUt fest, ob bereits 

15 eine Datei mit Nachrichten vom SCP vorhanden ist (Obergabedatei 204 aus 
Figur 2 bzw. 307 aus Figur 3). Falls ja, werden diese Daten beziigiich der 
SCP-Antwortzeiten analysiert xmd bei der Generierung der Ereignisfolgen 
durch den Verkehrs-Simulator beriicksichtigt. Falls nein, wird ohne Analyse 
zum nachsten Schiitt iibergegangen und fiir die SCP-Antwortzeiten ein 

20 Default-Wert verwendet. Die InitialLsierung der Zahler beinhaltet das Setzen 
einer intemen Simidationsuhr auf den Zeitpunkt Null und das Initialisieren 
der Zustandsvariablen xmd statistischen Zahler mit Anfangswerten. 

Im folgenden Schritt wird ein Startereignis generiert, also eine erste 
25 Nachiicht PROVIDE INSTRUCTION, xmd in den Ereigniskalender 

dngetragen, Der Ereigniskalender enthalt wahrend der Simulation alle noch 
abzuarbeitenden Ereignisse, geordnet nach ihrem Startzeitpunkt. 

Nach der InitialLsierung begiimt innerhaU) einer Schleife die eigenthche 
30 Simulation. Es folgt zunachst die Abfrage der Abbruchbedingung, wobei die 
Simulation dann abgebrochen wird, wenn die aktueUe Simulationszeit t 
grofier als eine vorgegebene Simulationsdauer ist, Innerhalb der Schleife wird 
zimachst das nachste Ereignis aus dem Kalender ausgetragen und die 
Simulationsuhr auf den Zeitpunkt des folgenden Ereignisses 
35 weitergeschaltet. Beim Start der Simulation ist dieses nachste Ereignis das 
nach der Simulation erzeugte erste Ereignis. Der Ereignistyp des 
abzuarbeitenden Ereignisses wirdbestimmt und darauffolgend die 
dazugehorige Ereignisrontine abgearbeitet. 
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In diesem Beispiel sind neun verschiedene Ereignistypen vorgesehen. Von 
links nach rechts sind dies das Eintreffen eines neuen Anrufs (NEWCALL), 
das Eintreffen eines wiederholten Anrufsversuchs (FOCALL, der Erhalt der 
5 Nachricht CREATE^JOIN vom SCP (CONNECTSSPCON), 

Verbindungsaufbau zum B-Teilnehmer (CONNECT B), Anrufumleitung 
(REROUD, der Erhalt der Nachricht CREATE-JOIN vom SCP bei 
Anrufumleitung (ElEROUTCON), Gesprachsende (TALKEND), Ende einer 
Ansage (TAPEND) sowie die Abweisimg eines Anrufe (REJECT). 

10 

Bei dem ersten im Kalender eingetragenen Ereignis handelt es sich in der 
Regel urn einen neuen Anruf (NEWCALL). Die dem zugeordnete 
Ereignisroutine veranlaBt den Verkehrs-Generator zur Generierung des 
nachsten Anrufs sowie zur Simulation des Verbindxmgsaufbaus zum SSP. Die 
15 Ereignisroutine NEWCALL simuhert das Senden einer IN-Nachricht 

PROVIDE INSTRUCTION vom SSP an den SCP durch Generierung eines 
entsprechenden Ereignisses und Eintragung in den Ereigniskalender bzw. in 
die Ubergabedatei. 

20 Der SCP sendet daraufhin die Nachricht CREATE-JOIN an den SSP; in der 
Simulation wird daher der Erhalt des CREATE-JOIN vom SCP als Ereignis 
zum Zeitpimkt aktueUe Simulationszeit plus SCP-Antwortzeit in den 
Ereigniskalender eingetragen. Damit ist die erste Ereignisroutine beendet, die 
Simulationsuhr wird zum nachsten Ereigniszeitpimkt vorgesteUt, dieses 

25 Ereignis aus dem Kalender gelesen vmd bearbeitet, falls nicht die 
Simulationszeit schon abgelaufen ist. Die Zeitdauer zwischen zwei 
Ereigrdssen wird ubersprungen. 

Angenommen, das nachste Ereignis ist der Erhalt der Nachricht CREATE- 
30 JOIN vom SCP. Dann wird die Fortsetzung des Verbindungsaufbaus vom SSP 
mit der Ereignisroutine (CONNECTSSPCON) simuliert. Dabei wird 
beispielsweise mit den oben geschilderten Wahrscheinlichkeiten ermittelt, ob 
ein Verbindungsaufbau zum B-Teihiehmer gelingt (Folgeereignis 
CONNECTB), wobei der B-Teilnehmer ein realer Teihiehmer oder eine 
35 Ansage sein kann, oder ob ein Ruf nach zuvor erfolglos versuchter 

Weitervermittlung umgeleitet werden mufl'(Folgeereignisse (CONNECTB 
Oder REROUT). Beim Aufruf des Ereignisses CONNECTB wird die 
Verbindung zum B-Teihiehmer aufgebaut. Die Folgeereignisse sind Talk-End 
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bzw. Tape-End> deren Zeitpunkte sich aus dem mittleren Anruf bzw. 
Ansagendauer sowie der aktuellen Simtdationszeit ergeben. IWfiBlingt der 
Verbindungsaufbau, wird mit gewisser Wahrscheinlichkeit ein Folgeanruf 
erzeugt und das Ereignis FOCALL in den Ereigniskalender emgetragen. Der 
5 wiederholte Anrufv^ersuch wird im folgenden wie ein erster Anrufeversuch 
behandelt. 

Die Schleife Aufruf eines Ereignisses aus dem Ereigniskalender, Durchlaufen 
der entsprechenden Ereignisroutine, ggf. Erzeugen eines Folgeereignisses und 

10 Eintragung desselben in den Ereigniskalender, Setzen der Simulationszeit auf 
den Zeitpunkt des nachsten, im Ereigniskalender eingetragenen Ereignisses, 
sowie Aufruf desselben wird solange durchlaufen, bis die zuvor eingesteUte 
Simulationszeit errreicht ist, bzw. bis ein Ereignis auffadLtt, welches das Ende 
der Simxilation kennzeichnet, Nach Simidationsende stehen die im 

15 Ereigniskalender oder in Protokolldateien eingetragenen, vom Simxdator 
erzeugten und abgearbeiteten Daten zur Auswertung der Performance des 
Intelligenten Netzes bzw. einzelner Komponenten zur Verfiigung. 

Pigur 8 zeigt den prinzipiellen Simulationsablauf im Online-Modus. Ztmachst 

20 wird die Konfiguration vom Benutzer bestimmt, wobei die entsprechenden 

Konfigurationsdateien von den Simulationsmodulen eingelesen werden, Im in 
Figur 8 gezeigten Beispiel sind der Verkehrs-, SS7-, SCP-, sowie 
Uberlastabwehr- (ACG- Simulator) aktiv und werden durch das gem ei nsame 
Organisationsprogramm, den Online-Simulator, verwaltet. Wie in den 

25 Ausfiihrungen zu Figur 7 besckrieben, wird zunachst durch den Verkehrs- 
Simulator ein Startereignis erzeugt. Die giobale Simulationsuhr wird auf t=0 
gesetzt. Innerhalb einer Schleife werden nun wie beim in Figur 7 
dargestellten Simulationsablauf die in den globalen Ereigniskalender 
eingetragenen Ereigmsse in chronologischer Reihenfolge aufgerufen, die 

30 dazugehorenden Ereignisroutinen abgearbeitet und gegebenenfalls erzeugte 
Folgeereignisse in den ^obalen Kalender eingetragen. Jeweils nach 
Beendigung einer Ereignisroutine wird die Simulationszeit auf den Zeitpimkt 
des nachsten Ereignisses vorgesteUt und dieses bearbeitet. Als 
Abbruchbedingung fiir die Schldfe dient wiederum eine vorbestimmte 

35 maximale Simulationszeit, die bei jedem Schleifendurchlauf mit der aktuellen 
Simulationszeit verghchen wird. Wenn das Simulationsende erreicht ist, 
werden die Teilsimulationen durch Freigabe des dynamischen Speichers 
beendet. Ist das Simulationsende nicht erreicht, wird der 
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Gemeinschaftsspeicher, auf den die BenutzeroberfLache wahrend der 
Simulation zugreift, aktualisiert, so daB die aktueUen Systemdaten dem 
Benutzer unmittelbar angezeigt werden konnen. Weiterhin werden die 
Systemdaten fur die Uberlastabwehr- Simulation aktualisiert. SchlieBlich 
5 werden in konstanten Zeitabstanden die ermittelten Mefidaten, also SCP- 
Auslastung, Warteschlangenlange usw., protokolHert tmd in die 
entsprechenden ProtokoUdateien eingetragen und/oder dem Benutzer 
visuaHsiert. AnschUeBend folgt die Abarbeitung des nachsten im Elalender 
vorhandenen Ereignisses. 

10 

Bei dem hier dargesteUten Beispiel werden insgesamt 13 ^obale 
Ereignistypen imterschieden, die sich in zwei Gruppen unterteilen lassen: 

Interne Ereignisse: Bei den intemen Ereignissen handelt es sich Mm 
15 Routinen, die den Zustand nur ernes einzebaen Simulationsmoduls 

beeinflussen, Jedes Simulationsmodul ist dabei ein eigenstandiges ereignis- 
orientiertes Programm mit einer Vielzahl von Ereignissen und einem eigenen 
lokalen Kalender zu deren Verwaltung. Aus der Sicht der Ablaufsteuerung 
des Gesamtsimulators existieren in diesem Beispiel drei globale interne 
20 Ereignisse TRAFIC INTERN, SS7 INTERN und SCP INTERN, die jeweils 
Verweise auf die lokalen Ereigmsskalender darstellen. 

Figur 9 zeigt dazu schematisch die Abarbeitung eines solchen intemen 
Ereignisses aus der Sicht der Online-Simulation. Beim AujBruf der jeweiligen 

25 Teilkomponente wird in Abhangigkeit vom intemen Programmablauf das 

nachste interne und gegebenenfalls das nachste exteme Ereignis erzeugt und 
in den lokalen Kalender des Simulationsmoduls eingetragen. ZusatzJich 
werden aUe benotigten Parameter des Ereignisses an die Ablaufsteuerung 
iibergeben, um in den globalen Kalender der Gesamtsimulation einsortiert zu 

30 werden. 

Die librigen Ereignisse des in Figur 8 dargesteUten Simulationsablaufe sind 
exteme Ereignisse, die zur Kommunikation zwischen den 
SimulatLonsmodulen dienen. Sie entsprechen den in eineni realen 
35 intellLgenten Netz von einer Komponente zu einer anderen gesendeten 

Nachrichten, z.B. PROVIDE INSTRUCTION, CREATE-JOIN, EVENT. Die 
hier auftretenden extemen Ereignisse sind: PROINST TO SS7, EVENT TO 
SS7 und SSP CALLEND TO SS7, die den Nachrichten PROVIDE 
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INSTRUCTION, EVENT bzw. EVENT(CALL END) des SSP an den SCP 
entsprechen. Die genannten intemen Ereignisse werden vom Verkehrs- 
Simulator erzeugt (Routine: TRAFFIC INTERN) und finden ihre 
Entsprechnng im Datei- Modus in den Ereignissen, die in der ersten 
5 Ubergabedatei 304 (Figur 3) eingetragen sind. 

Die extemen Ereignisse PROVINST TO SCP, EVENT TO SCP und CALL 
END TO SCP stehen fur die Nachrichten PROVIDE INSTRUCTION, EVENT 
bzw. EVENT(CALL END), die vom SS7-Systems bzw. vom SRP/STP an den 
10 SCP xibergeben werden. Diese Ereignisse entprechen damit den in der zweiten 
tibergabedatei 305 (Figur 3) eingetragenen Ereignissen. 

Die Antwort des SCP besteht in den Ereignissen SCP CALL END TO SS7 
sowie CREATE-JOIN TO SS7. Ersteres Ereignis bestatigt die 

15 Verbindungsauslosung, das zweite simuliert die Ubermittlung von 

Verbindungsaufbatdnformationen. Diese Ereignisse entsprechen den in der 
diitten Cfbergabedatei 306 eingetragenen Ereignissen. Sie werden vom SCP- 
Simidator erzeugt und richten sich an den SS7-Srmulator. Die extemen 
Ereignisse CALL END TO SSP sowie CREATE-JOIN TO SSP werden vom 

20 SS7-Simulator erzeugt und stehen fur die Weitervermittlung einer Nachricht 
vom SCP an einen SSP durch das SS7- System. Die entsprechenden 
Ereignisse werden im Datei-Modus in der vierten Ubergabedatei 307 
gespeichert, 

25 Die Nachricht CALL END TO SSP wird nur im Falle eines inaktiven SS7 
benotigt. 

Die Abarbeitung eines extemen Ereignisses ionerhalb der Ablaufsteuerung 
besteht in der Eingabe der entsprechenden Nachricht ia eine der 

30 Simulationskomponenten. Dabei ist es mo^ch, daB die Komponente durch die 
Nachricht zur Erzeugung eines neuen intemen Ereignisses veranlaBt wird, 
welches dann an die Online-Simulation weiter- gegeben und in den globalen 
Kalender eingetragen wird. Nach Abarbeitung einer Ereignisroutine wird das 
nachste Ereignis aus dem globalen Kalender ausgetragen und die 

35 Simulationsuhr aktualisiert, d.h. auf den Startzeitpunkt dieses 
Folgeereignisses gesetzt. 
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Bei Abarbeitung des intemen Ereignisses TRAFFIC INTERN wird der 
Verkehrssiinulator aiifgerufen tind erzeugt einen neuen Ruf. Aiifgrund der 
aktuellen Belastung der iibrigen Simulationsmodtile wird entschieden, ob 
dieser neue Ruf durch die Uberlastabwehr (ACG) abgewiesen wird. Falls der 
5 Anruf durch die Uberlastabwehr abgewiesen wurde, wird diese Tatsache 
protokoUiert, und die Ereignisroutine ist beendet. Falls der neue Ruf nicht 
abgewiesen wurde, wird er in die Sinndation aufgenommen, d.h. das 
entsprechende Ereignis PROVINST TO SS7 in den globalen Ereigniskalender 
eingetragen. In eine ProtokoUdatei wird fiir den generierten Anruf ein neues 

10 Element eingefugt, wobei folgende Daten gespeichert werden: Die 

Identifikationsnummer des jeweiligen Rufes, welche bei seiner CJenerierung 
vom Verkehrssimulator erzeugt wird, die Dienste-Identifikationsnunmiem des 
Rufes, die Nununer des SSP an dem der Ruf ankommt, die 
Nadmchtenidentifikationsniimmer, d.h. ob die Nackdcht PROVIDE 

15 INSTRUCTION oder EVENT vorhegt. sowie der Zeitpunkt tl, zu dem fiir den 
aktueUen Ruf die entsprechende Nachricht PROVIDE INSTRUCTION oder 
EVENT generiert wurde. Im Laufe der Simulation wird diese ProtokoHzeile 
durch weitere Zeitmarken erganzt, und zwar nach Abarbeiten der Routine 
PROVINST TO SCP oder EVENT TO SCP durch den SS7-Simulator 

20 (Zeitmarke t2), nach Abarbeiten der Routine CREATE-JOIN SS7 durch den 
SCP-Simidator (Zeitmarke t3) sowie nach Abarbeiten der Routine CREATE- 
JOIN TO SSP durch den SS7- Simulator (Zeitmarke t4). 

Nachrichten vom Typ CALL END werden bei der Protokollienmg nicht 
25 beriicksichtigt, weil die diurch sie verursachten Verzogerungszeiten nicht zur 
Wartezeit eines IN-Anrufers beitragen und daher die Aussage liber die 
Antwortzeiten verfalschen wurden. Bei einer veranderten FragesteHung kann 
hingegen auch die Protokollierung entsprechender Zeitmarken sinnvoU sein. 

30 Die zweite und dritte Zeitkomponente enthalt nur dann giiltige Werte, wenn 
der SS7-Simulator wahrend der Simulation aktiv war. 

Da ein vollstandiger Datensatz zu einem einzelnen Ruf erst zu dem Zeitpimkt 
vorliegt, zu dem die Nachricht CREATE-JOIN am SSP angekommen ist, 
35 miissen die Daten zunachst zwischengespeichert werden. Bei der Generierung 
eines Anrufes wird ein neuer Datensatz angelegt, der wahrend des weiteren 
Programmablaufs um die noch fehlende Zeitkomponenten erganzt wird. Durch 



wo 99/48306 



PCT/EP99/01141 



34 

die Bildimg von Differenzen zwischen den einzelnen, zu einem Anruf 
gehorenden Zeitmarken konnen folgende Antwortzeiten ermittelt werden: 
t2 - tl: Verzdgerung einer Nachricht im SS7 auf dem Weg zxim SCP; 
t3 - 12: Verzogerung einer Nadudcht im SCP; 
5 t4 - 13: Verzogerung einer Nachricht im SS7 auf dem Weg zum SCP; 
t4 - tl: Gresamte Verzogerung einer Nachricht im IN. 

Die Netzauslastung wird wahrend des Simvdationsablaufes in konstanten 
Zeitintervallen gespeichert. Es werden keine rufspezifischen Informationen, 

10 sondem globale statistische Netzdaten gespeichert. Dabei werden 

vorzugsweise folgende GroBen protokoUiert: Die Zeit der aktuellen Messung, 
die Anzahl der in das IN gelangenden Anrufe pro Sekunde, der Anteil der 
Nachrichten, die sich zur Zeit in Bearbeitung im SS7 auf dem Weg zum SCP 
befinden, die Anzahl der Nachrichten im SCP sowie die Anzahl der 

15 Nachridhten im SS7 auf dem Weg zum SSP. 

Innerhalb des SCP- Simulators werden fiir jeden Prozessor die Auslastung, 
die Warteschlangenlange vmd die Anzahl der bearbeiteten Nachrichten 
(Dispatches) ermittelt und in einer ProtokoUdatei gepeichert. Der Online- 
20 Simulator greift auf diese Daten zu und schreibt die iiber alle CPUs 

ermittelten Werte in eine DateL Die Daten konnen wahrend der Online- 
Simulation durch die Benutzeroberflache dargesteUt werden. 

SchheiJlich werden anhand der Verkehrsdaten die Anzahl der belegten 
25 Leitungen von bzw. zu den SSPs ermittelt und als Funktion der 
Simulationszeit protokoUiert. 

Figur 8.a zeigt zur Erganzung von Figur 8 den Zusammenhang zwischen den 
verwendeten Ereignissen. Der Simxdator aus Figur 8 wurde um ein separates 

30 Modxd zur Simulation des SEP erganzt, das auch Teil des SS7-Simulators sein 
kann, weshalb hier auch Ereignisse vom Typ SEP JNTERN auftreten. Die 
vier intemen Ereignisse TRAFFIC„INTERN, SS7_INTERN, SRP_INTERN 
und SCP JNTERN veranlassn den Aufiruf eines Simulationsmoduls zwecks 
Bearbeitung eines Ereignisses. AUe weiteren extemen Ereignisse dienen dem 

35 Ubergang von einem Simulationsmodul zum nachsten. Das Startereignis bei 
der Gesamtsimulation ist immer eia Ereignis TRAFFIC_INTEEN, da der 
Verkehrssimxdator die Quelle der IN-Anrufe ist. 
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Jedes Simulationsniodiil kann nach der Abarbeitung eines intemen 
Ereignisses ein Folgeereignis zux Bearbeitung durch dasselbe 
Simulationsmodul generieren. Gleichzeitig kann eines der durch einen 
abgehenden Pfeil gekennzeidmeten extemen Ereignisse erzeugt werden. 
5 Diese Information erhalt der Online-Simulator vom jeweiligen 
Simulationsmodul. 

Der Aufruf eines extemen Ereignisses entspricht dem Senden einer Nachiicht 
zu dem jeweiligen anderem Knoten des IN. Beim Senden einer Nachricht 

10 unterscheidet macn drei Nachrichten, Diese finden sich in jeweils drei 

verschiedenen Ubergangen vom Verkehrsgenerator bis zum S CP-Simulator 
wieder. Es wird ein TRAFFIC_INTEIIN-Ereignis aufgerufen, das diese 
Nachricht generiert und innerhalb der Simulation eine eindeutige Nummer 
(CaDID) fur diesen Anruf vergibt. Darauf folgt entsprechend der Nachricht ein 

15 PR0INST-T0-SS7-, EVENT-T0-SS7- oder SSP-CALLEND-T0-SS7-Ereignis 
und ein weiteres TRAFFIC_INTERN-Ereignis, falls noch mehr Verkehr 
generiert werden soil. Das exteme Ereignis wird dann bearbeitet und hat ein 
SS7-INTEIlN-Ereignis zur Folge. Dieses generiert sich mehrmals 
hintereinander, bis die Bearbeitung im SS7-Teil des SSP beendet ist tmd ein 

20 extemes Ereignis zum SRP generiert wird. Die Nachricht andert sich dabei 
nicht, d.h. ein eiagehendes PROVTDE-INSTRUCTION wird auch als solches 
weitergegeben. Auf dieses exteme Ereignis folgen dann analog zum SS7- 
INTERN-Ereignis mehrere SHP-INTEBN-Ereignisse. Die Ubergabe an das 
SCP-INTERN-Ereignis geschieht dann analog zur Ubergabe des SS7- 

25 INTERN-Ereignisses an das SRP-INTERN-Ereignis. 

Nach mehrmaligem Bearbeiten eines SCP-INTERN-Ereignisses beauftragt 
der SCP-Simtilator den Online-Simulator, eine Nachricht zum SSP-Simulator 
zu schicken. Hierzu gibt es zwei verschiedene Nachrichten CREATE- JOIN 

30 und CALLEND , die analog zum bereits beschriebenen Szenario bis zum SS7- 
Simulator weitergeleitet werden und zu einem SS7-INTERN-Ereignis fiihren. 
Allerdings fiihren von dort nur Ereignisse vom Typ CREATE- JOIN zu einem 
TRAFFIC-INTERN-Ereignis; Ereignisse vom Typ CALLEND veranlassen den 
Verkehrsgenerator nicht zur Erzeugung von dazugehorigen Folgeereignissen. 

35 Es konnen allerdings Folgeanrufe konfiguriert werden, die nach einer vom 
Zufallsgenerator zu bestimmenden Zeit vom Verkehrssimulator gestartet 
werden, wenn keine Verbindimg aufgebaut werden konnte. Diese haben die 
gleiche CalllD wie der urspriingliche Anruf. 
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Rpim Aufruf des Verkehrssimulators durch ein TRAFFIC-INTERN-Ereigiiis 
als Folge eines CREATE-JOIN-Ereignisses wird per Zufallsgenerator gemafi 
den vorbestimmten Wahrscheinlichkeiteii festgelegt, wann die nachste 
5 Nachricht zu diesem Ereignis abgesendet wird. Zu diesem Zeitpunkt wird 
dairn die oben besclmebene Ereigniskette gestartet. 

Bei mehr als einem Anruf wird fur jeden Anruf diese Ereigniskette 
beibehalten. Die Ereignisse mehrerer sich iiberschneidender Anrufe werden 
10 abhangig von ilirer Stellung im globalen Ereigniskalender behandelt. 

Im folgenden soil auf die Struktur des SCP- und des SS7- Simulators 
eingegangen werden. 

15 Figur 10 zeigt dazu schematiscli das Prinzip der SCP-Simulation. Es handelt 
sich wiederum um eine ereignisgesteuerte Simulation, wobei nur diskrete 
Ereigniszeitpunkte betrachtet werden und zu jedem Ereigniszeitpunkt 
Zustandsanderungen auftreten konnen. 

20 Der SCP-Simulator weist einen lokalen Ereigniskalender auf, in welchem 

samtiLLche vom SCP-Simulator zu bearbeitenden Ereignisse in chronologischer 
Reihenfolge eingetragen sind. Es werden folgende Ereignisse imterschieden: 
Nachrichten: Nachrichten reprasentieren Anfiragen des SSP bzw. SS7 an den 
SCP zur Anrufbehandlung, wobei die Ankunft einer Nachricht im SCP bzw. 

25 im SCP-Simulator ein Dienstbearbeitungsprogramm, bestehend aus einer 
vorbestimmbaren ProzeBfolge, startet. Eine Nachricht entspricht einem 
globalen extemen Ereignis. 

(Lokales) Intemes Ereignis: Ein lokales internes Ereignis fiihrt zur 
Beendigung eines Prozesses bzw. Ereignisses imd Generierung eines neuen 
30 Prozesses bzw. entsprechenden Ereignisses, wobei sich dessen Art und 
Eigenschaften aus der im Dienstbearbeitungsprogramm definierten 
ProzeBkette ergeben. 

(Lokales) Extemes Ereignis: Ein lokales extemes Ereignis wind erzeugt, wenn 
ein Dienstbearbeitungsprogramm beendet wurde, also nach Abarbeiten des 
35 letzten, in der ProzeBkette spezifizierten Prozesses. Ein extemes Ereignis 
fuhrt zum Senden einer Nachricht zum SSP bzw. zum SS7 und damit zur 
Generierung eines globalen extemen Ereignisses und dessen Eintrag in den 
globalen Ereigni skal enders. 
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Figur 11 zeigt ein Beispiel fiir KonfiguratLonsparameter des SCP- Simulators. 
Der obere Teil der Tabelle enthalt erne Auflistung samtLidier zu simiiliereiider 
Prozesse, die vom SCP durchfiihrbar sind und am Verbindimgsaufbau bzw. - 
5 abbau beteiHgt sini Die Einzelprozesse sind durch eiae ProzeB- 
Identfikationsnummer (ProzeBID) gekennzeichnet; die Angabe des 
ProzeBnamens dient lediglich zux einfacheren Anpassung der Konfiguration 
an die Funktion eines realen SCP. Jedem ProzeB ist eine ProzeBdauer, die 
hier in Mfllisekundeu angegeben ist, sowie erne Prioritat zugeordnet. Die 
10 Angaben sind benutzerdefinierbar, so daB sich beispielsweise die 

Auswirkungen einer veranderten Prioritatszuordnung oder einer veranderten 
ProzeBdaner mit dem Simulator ermitteba lassen. 

Im unteren Teil der TabeUe ist benutzerdefinierbar der SCP-Dienstablauf 
15 angegeben, Jedem Dienst, Mer gekennzeichnet durch die Dienste- 

Identifikationsnxnnmer, und dienstspezifisch jeder Nachricht PROVIDE 
INSTRUCTION, EVENT oder EVENT(CALL END), gekennzeichnet durch die 
Nachrichten-Identifikationsnummer ist eine ProzeB&lge zugeordnet. Die 
ProzeBfolge bzw. das Dienstbearbeitungsprogramm ist dabei durch 
20 aufeinanderfolgende Angaben der ProzeBIDs der oben aufgeKsteten Prozesse 
definiert. Weiterhin wird hier jede Nachricht dienstspezifisch einer CPU 
zugeordnet, auf welcher die ProzeBfolge abgearbeitet wird. Es konnen auch 
samtUche Nachrichten auf samtlichen verfiigbaren CPUs abgearbeitet 
werden. 

25 

Es ist weiterhin moglich, einen EinzelprozeB in belLebig viele Teilprozesse zu 
zerlegen, zwischen denen in der ProzeBfolge andere Prozesse stehen koimen, 
Belegt der erste TetlprozeB in einer ProzeBfolge die zxir ProzeBID gehorende 
Kopie, so bleibt diese so lange belegt, his der letzte TeilprozeB vollstandig 
30 abgearbeitet wurde. Eine solche Charakteristik besitzen alle Serviceprozesse. 

Urn einen Cache- oder Festplattenzugriff oder das Inkrementieren eines 
Zahlers fur den TV-Dienst zu simuheren, konnen Warteprozesse mit in die 
ProzeBfolge eingefiigt werden. Die mittlere Wartezeit imd deren Varianz ist 
35 dabei einzustellen; die tatsacUiche wird wahrend der Simulation auf grund 
eine gegebenen Wahrscheinlichkeitsverteilung mit diesen Parametem, z.B, 
GauB-Verteilung, daraus ermittelt. 
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WeiterhiQ ist, wie in Fig. 11 gezei^, als Parameter die Verzogerung des Front 
End Systems ST2000, das bei manchen Netztopologien die Schnittstelle 
zwischen dem SCP sowie dem SS7-System bildet, sowie der maximale 
Zahlerstand fur den Dienst Televotnm angebbar. 

5 

Figur 12 zeigt ein der SCP-Simulation zugrunde Hegendes ModeE der 
ProzeBverwaltung einer CPU 1201 innerhalb eines SCP. Piinzipiell kann 
jedoch jedes Modell einer solchen ProzeBverwaltung in den SCP-Simulator 
durch entsprechende Definition der Warteschlangen bzw. Ereigniskalender 

10 ubemommen werden. Die ProzeBverwaltung bestimmt ledigjich die Anzahl 
und Art der Verkniipfung der SCP- Warteschlangen bzw. der lokalen 
Ereigniskalender innerhalb des SCP-Simulators und damit, wie eine 
Nachricht bzw. die sich daraus ergebenden Einzelprozesse innerhalb des 
Simulators abgearbeitet werden. Der Simulator ist dabei in weiten Grenzen 

15 an Benutzerangaben anpaBbar, so daB beUebige Realitaten simtdiert werden 
konnen. Es ist keine bestimmte Hard- und/oder Softwarestruktur vorgegeben, 
sondem belieb:^e Konfigurationen konnen modeUiert werden. 

Die CPU 1201 ist im in Fig. 12 gezeigten Fall mitteLs zweier Local area 
20 Networks (LAN) 1202, 1203 an das SS7 angeschlossen, beispielsweise mit 
BBlfe zweier Token-Bus-LAN iiber das Front End System ST2000. 

Bei SCP ankommende Nachrichten 1208 (PROVIDE INSTRUCTION) werden 
in Abhangigkeit vom jeweiligen Dienst in dienstespezifische Warteschlangen 

25 1204, 1205, 1206, 1207 geschrieben. In dieser Warteschlange wartet ein 

ProzeB bzw. eine Nachricht auf exteme/inteme Nachrichten, die den ProzeB 
zur Bearbeitung aufrufen. Erhalt ein ProzeB die gewiinschte Nachricht, so 
reiht er sich in die Warteschlange der aktivierten Prozesse ein. In dieser 
Prioritatswarteschlange 1210 sind die aktivierten Prozesse nach Prioritaten 

30 geordnet, wahrend die in die dienstespezifischen Warteschlangen 1204 bis 
1207 eingetragenen Ereignisse chronologisch geordnet sind. Der ProzeB mit 
der hochsten Prioritat innerhalb der Prioritatswarteschlange 12 10 erhalt die 
CPU und wird dort bearbeitet. Falls beispielsweise ein ProzeB nicht von der 
CPU bearbeitet werden kann, weil alle Inkamationen des aufcurufenden 

35 Prozesses belegt sind, wird dieser nicht lauffahige ProzeB in einer 

zusatzlichen Warteschlange 1209 verwaltet, bis eine ProzeBinkamation 
wieder bereitsteht und der ProzeB in den laufFahigen Zustand iibergeht; dann 
wird er in die Prioiitatswarteschlange 1210 eingetragen. 
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Pigur 13 zeigt ein weiteres Modell der ProzeBverwaltimg einer CPU zur 
Simulation der SCP-Fxmktionen, An einer CPU 1301 ankommende 
Nachrichten werden gemaB dem Dienstebearbeitimgsprogramm in eine 
5 ProzeBfolge umgewandelt. Der erste dieser Prozesse wixd in eine 

prozeBspezifische Warteschlange 1302, 1303, 1304, 1305 eingetxagen, mn von 
der zugeordneten ProzeBroutine 1307, 1308, 1309, 1310 bearbeitet zu werden. 
In den prozeBspezifischen Warteschlangen 1302 bis 1305 sind die 
ankommenden Prozesse in chronologischer Folge eingeordnet. Jeder 
10 ProzeBroutine 1307, 1308, 1309, 1310 ist weiterhin eine bestimmte Prioritat 
PI bis Pn zugeordnet. Es sind auch Konfigurationen denkbar, in denen die 
Warteschlangen 1302, 1303, 1304. 1305 lediglich prioritatsspezifisch sind, d.li. 
alle, auch unterschiedHche Prozesse eine bestunmten Prioritat aufiiehmen, die 
daTiTi in chronologischer Reihenfolge abgearbeitet werden. 

15 

Die ProzeBroutinen konnen fiir den selben ProzeB in mehreren Inkamationen 
vorhanden sein, beispielsweise jeweils eine Kopie pro Dienst. In diesem Fall 
sind die prozeBspezifische Warteschlangen 1302 bis 1305 auch 
dienstespezifisch. Ist eine ProzeBroutine 1307 bis 1310 bereit, wird der 

20 nachste ProzeB aus der entsprechenden Warteschlange 1302 bis 1305 

aufgerufen; der ProzeB ist dann bereit. Ist zudem die CPU 1301 firei, wird der 
ProzeB bearbeitet. Nach Abarbeitung eines Prozesses wird durch die CPU 
1301 der in der ProzeBkette auf den abgearbeiteten ProzeB folgende ProzeB 
erzeugt und in die entsprechende Warteschlange eingetragen. Nicht 

25 laufEahige Prozesse werden in einer zusatzUchen Warteschlange 1306 
verwaltet, bis sie wieder in den lauffahigen Zustand iibergehen. 
Unterbrochene, aber lauffahige Prozesse werden an den Anfang ihrer 
Warteschlange gestellt und werden als nachstes bearbeitet, wenn es deren 
Prioritat zulaBt. 

30 

Unterbrochen werden laufende Prozesse beispielsweise durch Prozesse bzw. 
Ereignisse, die das Betriebssystem der CPU simulieren sollen. Solchen 
Ereignissen wird in der Simulation hohere Prioritat gegeben als den 
dienstbearbeitenden Prozessen. BenutzereinsteUbar ist, welche Zeit die CPU 
35 im Mittel auf die Bearbeitung solcher Prozesse verwenden m\iB. Ein 

derartiger ProzeB selbst wird dann durch einen ZxifaUsgenerator erzeugt. 



wo 99/48306 



PCT/EP99/01141 



40 

Figur 14 zeigt ein schematisches objektorientiertes Modell eines SCP- 
Simulators. Der Simulator weist eine Mehrzahl von Uatereinheiten auf, die 
jeweils die Funktion einer CPU 1401, 1402, 1403, 1404 simxilieren. Diese 
Untereinheiten sind modular zixm SCP-Simulator zusammensetzbar. 

5 

Eine ankommende Nachricht wixd vom Front End System ST2000, 
Bezugsziffer 1405, empfangen und je nach vorbestimmten CPU- 
Auswahlkriterien einer CPU 1401 bis 1404 zur vollstandigen Bearbeitung 
weitergegeben. Das Front End System 1405 wird dabei mit einer konstanten 
10 Verzogerungszeit simuliert. Es kann innerhalb des SCP-Simulators auch eine 
eigene Warteschlange aufweisen. 

Ein Polgeereignis, also z.B. die Nachricht EVENT oder EVENT(CALL END) 
wird automatisch auf der CPU bearbeitet, auf welcher schon das Erstereignis 

15 behandelt wurde, da in der Reahtat nur dort der Kontext zum Anruf 
gespeichert ist. Die Zuweisimg eines Erstereignisses (PROVIDE 
INSTRUCTION) zu einer CPU kann jedoch nach verschiedenen Kriterien 
erfolgen: Zum einen konnen Statistikdaten des SCP-Simulators herangezogen 
werden, z.B. die Auslastung der jeweiligen CPU, die Anzahl der Nachrichten 

20 zur Bearbeitung in der CPU zusammen mit dem momentanen Zustand der 
CPU (aktiv Oder iaaktiv), die Summe der verbleibenden Wartezeiten aUer auf 
der CPU laufenden bzw. wartenden Prozesse. Dies erfordert jedoch Rechenzeit 
wahrend der laufdenden Simulation zur Ermitdung der Statistikdaten xmd 
dementsprechender Entscheidungsfindimg. Altemativ ist daher die 

25 seUbstandige Nachrichtenaufiiahme durch die CPUs vorgesehen: Samthche 
Erstereignisse (entsprechend den Nachrichten PROVIDE INSTRUCTION) 
werden in eine alien CPUs gemeinsame Warteschlange geschrieben; die 
Folgeereignisse (entsprechend den Nachrichten EVENT oder EVENT(CALL 
END)) werden in CPU-spezifische, ggfs. auch CPU- imd 

30 nachrichtenspezifische Warteschlangen eingetragen. Falls der Prozessor einer 
CPU firei ist, kann automatisch die nachste Nachricht aus einer CPU- 
spezifischen oder axis der gemeiasamen Warteschlange gelesen werden. 

Das Ereignis durchlauft bei der Bearbeitung innerhalb der CPU-Simulation 
35 eine festgelegte ProzeBfolge, z.B. wie in Fig. 11 gezeigt, Jeder ProzeB der 
ProzeBfolge kanTi auch in eine Mehrzahl von Teilprozessen zerfallen, wobei 
zwischen den Teilprozessen andere Prozesse ablaufen konnen, Fiir jeden 
ProzeB existiert auf der CPU wenigstens eine ProzeBroutine 1408. 1409, 1413 
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s 1416, mit welcher die in die ProzeBwarteschlange 1410, 1411 
eingetragenen Prozesse bearbeitet werden, wenn sie an der Reilie sind. Eine 
ProzeBroutine kann auch in mehreren Inkamationen anf der CPU vorhanden 
sein, wobei beispielsweise die Zuordnung eiaes Ereignisses zu einer der 
5 ProzeBroutinen dienstespezifisch erfolgt. Dies ist in Figur 14 symbolisiert 
duxch zwei Blocke von ProzeBroutinen 1408, 1409, 1413 bzw. 1414 bis 1416 
mit jewefls einer ProzeBwarteschlange 1410 bzw. 1411- 

Ein ankommendes Ereignis wird wie folgt verarbeitet: 
10 Das Ereignis wird zunachst in die ProzeBwarteschlange 1410 bzw. 1411 
eingetragen und wartet darauf, daB die entsprechende ProzeBroutine des 
aufeurufenden Prozesses frei wird. Ist der ProzeB bereit, wird das Ereignis in 
die Prioritatswarteschlange eingereiht. Die in die Prioritatswarteschlange 
1407 eingetragenen Ereignisse werden von der CPU 1401 der Reilie nach 
15 abgearbeitet. Wahrend der Abarbeitung eines Prozesses durch die CPU 
konnen Warteereignisse auftxeten, die z.B. Zugriffe auf die Festplatte 
sLEnuHeren. Diese Warteereignisse werden zufaUig oder auch prozeBbediagt 
erzeugt und in einer Warteschlange 1412 eingetragen. Diese Ereignisse haben 
hohere Prioritat und unterbrechen einen auf der CPU 1401 laufenden ProzeB. 

20 

Wahrend der Abarbeitung eines Prozesses konnen diensteabhangig 
Zahlereignisse verlangt werden, die durch einen Zahler 1406 erzeugt werden. 
In diesem Zahler 1406 konnen von alien CPUs Anfragen eintreffen und sich 
gegenseitig blockieren. Dies fiihrt zu einer Verlangerung der 
25 ProzeBverarbeituQgszeiten, obwohl die aufirufende CPU dadurch nicht belastet 
wird. 

Die CPU-Auslastung wird vom SCP-Simulator zur Gewinnung von SCP- 
Statistikdaten wie folgt ermittelt: Zu jedem vom Benutzer angegebenen 
30 Zeitpunkt, z.B, alle n Simulationssekunden. wird berechnet, wieviel Prozent 
der Zeit ionerhalb des zuruckKegenden, benutzerdefinierten Zeitintervalls At 
die CPU aktiv war, d.h. alle Zeiten der innerhalb des letzten Zeitintervalls At 
gelaufenen Einzelprozesse werden addiert und ihr prozentualer Anteil am 
ZeitintervaU At berechnet. 

35 

Die Warteschlangenlange als weiteres Kriterium zur SCP-Belastung ergibt 
sich unmittelbar aus der Lange der jeweilLgen Warteschlangen bzw. lokalen 
Ereigniskalender. 
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Figur 15 zeigt die Anordnting der SS7-Schichten, die am Dialog zwischen SSP 
xrnd SCP beteiligt sind und daher mit dem SST-Simulator simuliert werden. 
Die oberste Schicht 1501 steUt die Schicht der SST-Benutzer dar, 

5 reprasentiert also die Anbindimg des SSP hzw, SCP an das SS7. Von hier 
werden Nachrichten in das InteUigente Netz bzw. das SS7 gesendet bzw, 
empfangen. Darunter ILegen in folgender Reihenfolge die TCAP-Schicht 1502, 
die SCCP-Schicht 1503 sowie die MTP-Schichten 1504 (Level 3 bis 1), die 
jeweils mit eigenen Prozessoren bestimmte SS7-Funktionalitaten realisieren. 

10 Der NachiichtenfluB vom SSP zum SCP erfolgt in der im rechten 

Zeichnungsteil skizzierten Weise von Schicht 1501 bis 1504 und zuriick zu 
1501, wobei der NachrichtenfluB bidirektional ist. 

Zur Simulation des SS7 werden die SS7-Ebenen 1502 bis 1504, also TCAP. 
15 SCCP, MTP 1-3, getrennt modelliert. Hierbei werden die einzelnen Prozesse 
einer Ebene durch Verzogerungszeiten nachgebUdet. Um den FluB der 
Zeichengabenacknchten innerhalb einer Ebene bzw. zwischen zwei Ebenen 
simulieren zu konnen, wird ein WarteschlangenmodeU benutzt. 

20 Als Beispiel ist dazu in Figur 16 die Modellierung der MTP3-Ebene 1008 des 
SRP innerhalb des SS7-Simidators dargestellt. Die drei in dieser Ebene 
auftretenden Prozesse sind MESSAGE DISTRIBUTION (HMDT), MESSAGE 
DISCRIMINATION (HMDC) und MESSAGE ROUTING (HMRT). Das 
Verhalten der Prozesse untereinander und mit den angrenzenden Schichten 

25 SCCP 1607 bzw. MTP2 1609 ist in Figur 16a als FluBdiagramm sowie in Figur 
16b als FluBdiagramm mit lokalen ProzeBwarteschlangen 1601, 1602, 1603 
dargestellt. 

Der ProzeB HMDC 1604 erhalt Zeichengabenachrichten von der Ebene MTP2 
30 und verteilt diese abhangig vom Zielknoten der Nachrichten. Vor der 

Bearbeitung durch den ProzeB HMDC 1604 werden die Nachrichten in die 
dazugehorige ProzeBwarteschlange 1603 eingeordnet. Fiir den eigenen 
Knoten, also fiir den SRP, der der MTP-Schicht 1608 zugeordnet ist, 
bestimmte Nachrichten werden an den ProzeB HMDT 1605 weitergeleitet Sie 
35 werden in die entsprechende ProzeBwarteschlange 160 1 einsortiert und nach 
Abarbeitung durch den ProzeB HMDT an den SCCP 1007 libergeben. Ist eine 
Nachricht fiir einen anderen Knoten bestimmt, wird sie vom ProzeB HMDC 
1604 an den ProzeB HMRT 1606 geleitet. Dieser gibt die Nachricht nach 
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Abarbeitung, also nach Aufraf aus der entsprechenden ProzelJwarteschlange 
1602, an die Ebene MTP 2 1609 weiter. Gleiches gilt fiir Nachrichten, die die 
Ebene MTP3 1608 vom SCCP 1607 erhalt. 

5 Die in Figur 16b verwendeten FIFO-Warteschlangen 1601, 1602, 1603 sind in 
der Lage, mehrere Zeichengabenachrichten aufetmelimen und nacheinander 
abzuarbeiten. Die Reihenfolge der Abarbeitung ist durch die jewedige 
Verzogerungszeit bestininit nnd wird in den lokalen Ereigniskalender des SRP 
bzw. SS7-Simulator eiagetragen. 

10 

Figur 17 zeigt als weiteres Beispiel die Modellierung der TCAP-Scbicht des 
SS7, GemaB der Darstellung in Figur 15 ist die TCAP-Schicht 1702 zwischen 
der Schicht der SS7-USER 1701 und der SCCP-Schicht 1703 angeordnet. Die 
Nachrichtenflusse zwischen den Schichten sowie innerhalb der TCAP-Schicht 

15 1702 sind durch Pfeile angedeutet. In der TCAP-Schicht 1702 werden in 
diesem Beispiel vier Prozesse simuliert, die Prozesse INVOCATION STATE 
MACHINE 1704, COMPONENT COORDINATOR 1705, DIALOG 
HANDLING 1706 sowie TRANSACTION SUB-LAYER 1707. Jedem dieser 
Prozesse ist eine ProzeBwarteschlange 1708 bis 1711 zugeordnet. Nach 

20 Abarbeitung eines in eine der Warteschlangen eingetragenen Ereignisses wrrd 
entsprechend dem hier dargestellten NachrichtenfluB ein FolgeprozeB 
derselben Schicht aufgerufen oder die Nachricht an die dariiber- oder 
darunterhegende SS7-Schicht weitergeleitet. Die ProzeBfolgen sind dabei 
benutzerdefinierbar und dem realen ProzeJJablauf innerhalb einer TCAP- 

25 Schicht flexibel anpaBbar. 

Figur 18 zeigt ein Beispiel fiir Konfigurationsparameter des SS7-Simulators. 
Es sind zunachst fiir die eruzehien SS7-Schichten die ProzeBzeiten fiir die an 
der Kommunikation zwischen SSP und SCP beteiligten Prozesse angebbar. 

30 Dabei werden in diesem Beispiel lediglich die ProzeBzeiten der TCAP- und 

SCCP-Prozessoren auf Seiten des SSP und des SCP sowie der Prozessoren auf 
der MTP3-Ebene im Bereich von SSP, STP und SCP angegeben. Es sind 
jeweils drei oder vier Prozesse pro Ebene beteiligt. Die ProzeBabfolge in den 
SS7-Schichten ist wie bei der SCP-Simulation das 

35 Dienstebearbeitungsprogramm vom Benutzer festlegbar und kann somit 

flexibel den realen Gegebenheiten angepaBt werden. Den einzehien Prozessen 
kann auch jeweils eine bestimmte Prioritat zugewiesen werden. was hier nicht 
dargesteUt ist. 



wo 99/48306 



PCT/EP99/01141 



44 



Im unteren Teil der in Figur 18 gezeigten Tabelle sind die 
benutzerdefimerbare Parameter angegeben, welche die Topologie des 
Intelligenten Netzes im Bereich des SS7 betreffen, 2.B. die Anzahl der SCPs, 
5 die Anzahl der Zeichenkanale zwischen SSP und STP sowie zwischen STP 
und SCP, die laufeeitbediagte Verzogerung einer Nachricht zwischen STP und 
SSP bzw- SCP sowie die Verzogerung zwischen den Prozessoren. Weiterhia ist 
die Nachrichtenlange angebbar. 

10 Figur 19 zeigt die Implementierung des Uberlastabwehr-Simulators 1903 in 
den nSf-Simulator im Onhne-Betrieb sowie dessen prinzipieUe 
Funktionsweise. Der Uberlastabwehr-Simulator 1903 reguliert in diesem 
Beispiel die vom Verkehrssimulator 1902 generierte bzw. weitergegebene 
Verkehrsmenge aufgrund von Systemdaten, die eine Aussage iiber die 

15 momentane Lastsituation, insbesondere des SCP-Simulators, zulassen, vom 
Online-Simulator 1901 verwaltet und dem Uberlastabwehr-Simulator 1903 
iiber die OnHne-SchnittsteUe iibergeben werden, 

Im hier gezeigten Beispiel reguliert der Uberlastabwehr-Simulator 1903 die 
20 vom Verkehrssimulator 1902 generierte bzw. weitergegebene Verkehrsmenge 
nach dem Prinzip des Automatic Call Gapping (ACG): Innerhalb eines 
Zeitintervalls Atl (gap time) wird beispielsweise jeweils nur eiu Anruf , ggfis. 
mit vorbestmunten Eigenschaften, vom SSP zum SCP durchgelassen. Das 
Zeitintervall At2 (gap duration) gibt dabei an, wie lange eiue solche 
25 ReduzierungsmaBnahme andauert. Auch der Uberlastabwehrmechanismus 
nach dem Prinzip des "Leaky Bucket" kann mit dem Uberlastabwehr- 
Simulator 1903 nachgebildet werden. 

Der Uberlastabwehr-Simulator 1903 (Overload ProzeB) wird vom 
30 Verkehrssimulator 1902 aufgerufen. Dabei iibergibt er einen Anruf mit den 
entsprechenden Parametem, wie z.B. Dienste-, Nachrichten-, SSP- 
Identifikationsnummer, Zeit. Neben diesen Daten erhalt der Overload ProzeB 
die aktuellen Systemdaten, wie z3. CPU-Auslastung, Antwortzeiten und 
Warteschlangenlange, vom Online-Simulator 1901. Der einmal initialisierte 
35 Overload ProzeB steuert sich mit Hilfe der eigenen Zahler und der 

ubergebenen Systemdaten. Fiir jeden SSP, Dienst und/oder Diensteklasse 
TraTiTi ein eigener Zahler vorhanden sein. Nachdem der Anruf in dem 
entsprechenden Zahler erfaBt wurde, berechnet der Uberlastabwehr- 
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Simulator den aktuellen Uberlastlevel mit Hilfe der Systemdaten. 
AnschlieBend werden die Gap-Parameter fur den aktuellen Uberlastlevel aus 
der Initialisierungstabelle ausgelesen. Die InitialisierungstabeUe ist in der 
Initialisierungsdatei abgelegt. die beim Start des Uberlastabwehr-Simulator 
5 1903 aufgerufen wird. Die Gap-Parameter sind beispielsweise das 

Zeitintervall Atl (gap time), innerhalb welchem nur jeweils ein Anruf, ggfs. 
mit bestimmten Eigenschaften, vom SSP znm SCP durchgelassen wird, sowie 
das Zeitintervall At2 (gap duration), das angibt, wie lange eine seiche 
ReduzierungsmaCnalane andauert. 

10 

Fiir die Berechnung des aktuellen Uberlastlevels werden innerhalb eines 
vorbestimmbaren Zeitfensters alle Anrufe gezahlt und gegebenenfalls zeithch 
gewichtet. Die Wichtimg hangt vorzugsweise exponentieU vom Alter des 
Anrufe ab, wobei ein jungerer Anruf starker gewichtet wird als ein langer 
15 zuriickliegender. Es erfolgt weiterhin eine Aufteilung der Last auf die SSPs 
bzw. auf die Dienste, um auch dienste- und/oder SSP-abhangige 
tiberlastabwehr simulieren zu konnen, bei welcher selektiv Anrufe mit 
bestiamiten Eigenschaften unterdriickt werden. 

20 Es sind verschiedene Uberlastlevel vom Benutzer definierbar, denen 
benutzerdefinierte Gap-Parameter zugeordnet sind. 

Nach der Berechnung des Uberlastlevels werden die Gap-MaUnahmen 
entsprechend aktualisiert, z.B. die Lange der Zeitintervalle Atl bzw. At2 
25 angepaBt. Es wird dann gepriiffc, ob der aktueUe Anruf einer solchen 

MaBnahme imterliegt oder nicht. Dem aufzurufenden ProzeB wird dann im 
Erfolgsfall der Riickgabewert TRUE oder eine andere Kennzeichnung 
ubergeben, ansonsten der Wert FALSE bzw. eine andere, dem zugeordnete 
Kennzeichnung. 

30 

Der Riickgabewert wird vom Verkehrssimulator 1902 ausgewertet. Im 
FALSE-Fall wird miteiner voreingestellten Wahrscheinlichkeit ein Folgeanruf 
generiert, Im TRUE-Fall wird der Anruf vom Verkehrssimulator 1902 an die 
Online-Schnittstelle weitergereicht, von dort wird der Anruf dem SCP- oder 
35 SS7-Simulator iibergeben. Der Verkehrssimulator erzeugt daraufhin einen 
neuen Anruf, imd der ProzeB beginnt von neuem. 
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Figur 20 zeigt die Implementienmg des Uberlastabwehr-Simxilators 2002 in 
den IN-Simulator im Datei-BetxLeb. Im Datei-Betrieb warden die Anrufe zuvor 
mit dem Verkehrssimulator generiert nnd in einer Ubergabedatei 2001 
abgelegt- Da im Dateibetrieb keine aktuellen Systemdaten an den 
5 Uberlastabwehr-Simulator 2002 ubergeben werden konnen, miBt er selbst die 
aktuell anliegende Last in Form von Anrufen pro Zeiteinheit. Die aktuelle 
Last wird mit einem vorbestimmten Wert fiir die maximale Anz a hl vom 
Verkehrssimulator ausgehender Anrufe ver^chen; dieser ist beispielsweLse in 
der InitiaHsierungsdatei gespeichert- Aus aktueUer eingehender Last und 
10 maximaler ausgehender Last wird der aktueUe Uberlastlevel berechnet. 

Analog zum Online-Betrieb werden anschlieBend die neuen Abwehrparameter 
aus der Initialisierungstabelle ausgelesen und die AbwehrmaBnahmen 
aktuahsiert. 

15 Figur 2 1 zeigt ein Beispiel fiir mit dem IN-Simulator ermittelte 

Simulationsdaten. Es wurde dabei die Konfiguration zugrunde gelegt, die sich 
nach den Figuren 6, 11 und 18 aus den dort dargestellten 
Konfigurationsdateien ergibt. Der SS7-Simulator ist aktiv, wahrend der 
Uberlastabwehr-Simulator abgeschaltet ist. Es wurde ein Telefonverkehr von 

20 30 Anrufen pro Sekunde im ZeitintervaH 0 bis 500 Sekunden vorgegeben. 

Die Figuren 2 La bis c zeigen die vom Simulator ermittelten Daten zur 
Netzstatistik- In Figur 21.a ist der vorgewahlte mittlere Telefonverkehr sowie 
der vom Verkehrssimulator generierte Telefonverkehr jeweils als Funktion 

25 der Simxilationszeit dargestellt. Der eingesteUte Telefonverkehr ist gestrichelt 
dargesteUt und entspricht den obengenannten Vorgaben, d.h. betragt im 
IntervaU 0 bis 500 Sekunden konstant 30 Anrufe pro Sekunde, danach 0 
Anrufe pro Sekunde. Der generierte Telefonverkehr, dargestellt als 
diurchgezogene linie zeigt statistische Schwankungen um den vorgewahlten 

30 Mittelwert. Er fallt etwas nach dem Zeitpunkt t = 500 s auf NxiU ab. 

Figur 21.b zeigt die SCP-Antwortzeit in Sekunden als Funktion der 
Simulationszeit. Bei dem konstanten Telefonverkehr von ca. 30 Anrufen pro 
Sekunde steUt sich gemafi diesem Simulationsergebnis ein eingeschwungener 
35 Zustand ein, d.h., der SCP arbeitet die an ihn gestellten Anfragen mit einer 
Antwortzeit von 0,4 bis 0,7 Sekunden ab. 
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Figur 2 l.c zeigt die Anzahl der Nachiichtea, die sich zur Abarbeitung im SCP- 
Simulator befinden, als Funktion der Sixnulationszeit. ErwartirngsgemaB sind 
die Anzahl der Anrufe im SCP uud die Antwortzeit des SCP stark miteiaander 
korreUert, 

5 

Die Figuren 21.d-f zeigen SCP-Statistikdaten als Funktion der Zeit, und zwar 
die Auslastung der CPUs in %, die Anzahl der Nachrichten in einer CPU- 
Warteschlange sowie die Anzahl von einer CPU bearbeiteten Prozesse pro 
Zeiteinheit. Es ist jeweils die maximale, minimale und mittlere CPU- 

10 Auslastung, Warteschlangenlange und Anzahl der Dispatches dargestellt. Die 
Anzahl der Nachrichten, die sich zu einer bestimmten Zeit im SCP in 
Bearbeitung befinden, schwankt gemaB Figur 2 l.c im Mittel zwischen 20 und 
60, wahrend sich in der Warteschlange, Figur 21.e, nur durchschnittlich 6 
Nachrichten befinden. Auf diesen Werten, sowie auch axis der mittleren CPU- 

15 Auslastung von 80 % laBt sich erkennen, daB der SCP bei der gewahlten 
Konfiguration ein Verkehrsaufkommen von 30 Anrufen pro Sekunde ohne 
Probleme verkraftet, 

Figuren 21.g-i, zeigen SST-Statistikdaten. Figur 21.g entspricht 21.a undzeigt 
20 den eingestellten bzw. generierten Telefonverkehr als Funktion der 

Simulationszeit. Figur 21.h zeigt die Verzogerung einer Nachricht im SS7- 
Simulator auf dem Weg vom SSP zum SCP feestrichelt) als Fxmktion der Zeit, 
sowie die Verzogerung einer Nachricht auf dem Weg vom SCP zum SSP 
(gepunktet), Figur 21.i zeigt die Anzahl der Nachrichten im SS7 in Richtung 
25 SCP (gestrichelt) bzw. in Hichtung SSP (gepunktet) als Funktion der 

Simulationszeit. Die Verzogerungszeiten im Zeichengabesystem Uegen weit 
unter denen des SCP und erreichen einen Maximalwert von 0,045 Sekunden. 

Figur 21.j zeigt die SSP-Statistikdaten als Funktion der Zeit, d.h. die Anzahl 
30 der belegten Leitungen von und zu SSPl bzw. SSP2 (linke bzw. rechte 

Kurven). Die Anzahl der belegten Leitungen von und zu den SSPs erreicht bei 
ungefahr 300 einen stationaren Zustand Ztmi Zeitpunkt T = 300 Sekunden 
wechselt der gesamte Telefonverkehr vom SSPl zum SSP2. Dies wurde in der 
Verkehrsdatei so eingesteUt. 

35 

Figur 22 zeigt ein weiteres Beispiel fiir mit dem IN-Simulator ermittlte 
Simxdationsdaten, hier bei einem stark wechsehaden Verkehrsaufkommen. 
Das Verkehrsaufkommen wurde alle 100 Sekunden geandert, vmd zwar von 
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40 axif 20, auf 80, avif 10. auf 50 mid auf 5 Aimife pro Sekunde. Der SS7- 
Simtilator ist aktiv, wahrend die Uberlastabwehr inaktiv ist. Die Zuordnimg 
der Abbildungen zu den simulierten GroBen entspricht der ia Figur 21. 

5 Figur 22,a zeigt, daB der generierte Verkehr dem eingestellten 

Verkehrsaufkommen bis zum Zeitpunkt t = 250 s folgt, wobei das generierte 
Verkehrsaufkommen dnrch statistische Fluktuationen verzerrt ist. Zum 
Zeitpunkt t = 250 s bricht das generierte Verkehrsaufkommen, also die Anzahl 
der in das IN gelangenden, vom Verkehrs-Simulator erzeugten Nachrichten 
10 gegeniiber den Vorgaben stark ein. Dies ist mit Hilfe der Abbildung 22.j zu 
erHaren. Alle in das Netz fiihrenden Leitungen sind zur Zeit t = 250 s belegt, 
so daB nur noch ein geringer Teil der Anrufe zu einem IN-Ereignis fuhren 
kann. 

15 Ohne den Eingriff der Uberlastabwehr kommt es in der in Figur 22 

dargestellten Simulation zu starken Anstiegen der SCP-Antwortzeit, sobald 
die Grenze von 30 Anrufen pro Sekunde iiberschritten wird. Die Anzahl der 
Anrufe im SCP sowie die SCP-Warteschlangenlange nimmt ebe nf al l s stark zu. 
Sobald dieser Grenzwert von 30 Anrufen pro Sekunde xmterschritten wird, ist 

20 es dem SCP moglich, die wartenden Nachrichten abzuarbeiten, so daB die 
Verzogerungszeit und auch die Lange der Warteschlange abninmit. 
Die Verarbeitungszeit der Nachrichten im zentralen Zeichengabesystem 
schwankt trotz der unterschiedHchen Verkehrsmengen urn nur 0,02 
Sekunden. 

25 

Figur 23 zeigt eine Simulation mit demselben eingestellten 
Verkehrsaufkommen wie bei Figur 22, hier jedoch mit aktiviertem 
tiberlastabwehr-Simulator. Dem Ubedastabwehr-Simulator wurde ein 
maximales Verkehrsaufkommen von 30 Anrufen pro Sekunde vorgegeben. In 

30 Figur 23.a ist die Begrenzung des generierten Verkehrsaufkommens auf diese 
durchschnittiich 30 Anrufe pro Sekunde sichtbar. Die Antwortzeit des SCP, 
Figur 23.b wird daher auf einen Wert von etwa 0,4 bis 0,5 Sekimden gesenkt, 
was den im Beispiel der Figur 2 1 zu einem konstanten Verkehrsaufkommen 
von 30 Anrufen pro Sekunde ermittelten SCP-Antwortzeiten entspricht. Die 

35 Antwortszeiten sind damit um den Faktor 100 kleiner als beim Beispiel der 
Figur 22. 

Gewerbhdbie Anwendbarkeit: 
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Der erfindungsgemaBe DSf-Simulator ist in alien Stadien der Planung sowie 
des Betxiebs eines Intelligenten Kommunikationsnetzwerkes ein sinnvolles 
Werkzeug, nm die Performance des Netzes zu testen, bestimmten Vorgaben 
5 anzupassen sowie Schwachstellen aufeuspiiren. Durch die groBe Flexibilitat 
der Simulationsmodule ist eine Anpassung an gegebene, aber auch an 
znkunflige Realitaten problemlos mo^ch. Durch Vergleich mit simulierten 
Werten und den der Simulation zugrunde liegende Parametem gelingt es, die 
Konfiguration des realen Intelligenten Netzes so zu wahlen, daB unter den 

10 gegebenen Randbedingungen eine bestmogliche Effizienz des IN realisiert 

wird. Dies fuhrt zu erhebHchen Kosteneinspanmgen beim Betrieb und bei der 
Planung Intelligenter Netze, da mit Hilfe der IN-Simulation die optimale 
Konfiguration des Intelligenten Netzes und seiner Komponenten ermittelt und 
direkt in die Realitat umgesetzt werden kann, ohne daB kostenaufwendige 

15 Experimentierzeiten am realen IN notwendig werden. Der IN-Simulator ist 
eia geeignetes Werkzeug zur Ermittlung von Management-Parametem, die 
Z.B. die problematische Uberlastabwehr auf eine stabile Basis steUen konnen. 
Die Ergebnisse der Simulation ermoglichen auch die Entwicklimg und 
tnberpriifimg von allgemeiaen globalen oder netzknotenbezogenen 

20 Managementfunktionen, die effektiver realisiert und eingesetzt werden 
konnen als die bisher verwendeten Uberlastabwehrmechanismen. 
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Liste der Bezugszeichen: 

Vermittlungsstdle 
SSP 

5 STPbzw.SRP 

SCP-Eingangsprozessor 

Telefon-Nutzkanale 

SS7-Kanale 

SCP 

10 Verkehrs-Simulator 
SCP-Simulator 
SS7-Simulator 
Ubergabedateien 

15 SCP-Ausgabedatei 

Verkehr-Ausgabedatei 
SS7-Ausgabedatei 
SCP-Eingabedatei 
Verkehr-Eingabedatei 

20 

SST-Eingabedatei 
Uberlastabwehr-Simulator 
Benutzeroberflache 
Protokolldateien 
25 Dateiaamen-Datei 

Uberlastabwehi-Eingabedatei 

"Black box" 

CPU 

LAN (zum AnschluB an das SS7) 
30 Dienstespezifische Warteschlangen 
IN-Nachricht/Ereignis 
Warteschlange fiir nicht lauSahige 
Prozesse 

Prioritatswarteschlange (fur aktivierte, 
35 lauSahige Prozesse) 

ProzeBspezifische Warteschlange 



101 
102 
103 
104 
105 

106,107,108 
109 

201,301,401, 1902 

202,302,402 

303,403,503 

203,204,304,305.306,307, 

406-409, 2001 

205,308,423 

206,309 

310 

207,311,416 
208,209,210,211,212, 
312-316, 411-414 
317,415 

404,502, 1903, 2002 
410 

417-420 
421 
422 
501 

1201,1301,1401,1402,1403,1404 
1202,1203 

1204, 1205, 1206, 1207, 1410, 14 1 1 
1208 

1209,1306 
1210,1407 

1302, 1303, 1304, 1305, 160 1, 
1602,1603 
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ProzeBroutme 



Front-End-System ST2000 
Zahler 

"Warteereignis" 

SS7-Userschicht 

TCAP-Schicht 

SCCP-Schicht 

MTP-Schicht 

Online-Simiilator 



1307-1310. 1408, 1409, 

1413-1416, 1604,1605,1606, 

1704-1707 

1405 

1406 

1412 

1501,1701 

1502,1702 

1503,1703,1607 

1504, 1505, 1506, 1608, 1609 

405, 1901 
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Patftntanspmche 

1. Simulator zur Simulation dnes Intelligenten Netzwerks (EN), das aus 
wenigstens einem Service Switching Point SSP (102), an wdchen Anrufe mit 

5 IN-spezifischen Rujaiummem vermittelt werden, einem Service Control Point 
SCP (109), welcher einem SSP Informationen zur Anrufweiterbehandlung zur 
Verfiigung steUt, sowie einem Zeichengabesystem Nr. 7 (SS7), iiber welches 
der Dialog zwischen SSP (102) und SCP (109) stattfindet, besteht, wobei der 
Simulator folgende Komponenten aufweist: 
10 1.1. Ein Modul (201, 301, 401) zur Simulation behebiger IN-typischer 

Ereignisfolgen (Verkehrssimulator) nach den Regeln der Verkehrtheorie; 
1.2. einem Modul (202, 302, 402) zur ereignisorientierten Simulation des 
Service Control Point (SCP-Simulator) unter Verwendimg von 
ProzefimodeUen; 

15 1.3. Mittel (203, 204, 304-307, 406-409) zur Dateniibergabe zwischen den 
Modulen; 

1.4. Mittel (207, 311, 416, 208-212, 312-317, 411-415) zur Eingabe und 
Speicherung der Netzkonfiguration, Kommxmikationsdienstespezifikation und 
sonstigen Simulationsparametem sowie deren Ubergabe an die 

20 entsprechenden Module; 

1.5. Mittel (205-207, 308-310, 417-420, 423) zur Ausgabe und/oder 
Speicherung der simuUerten Daten. 

2. Simulator nach Anspruch 1, dadurch gekennzeichnet, 

25 daB ein Modul (303, 403, 503) zur ereignisorientierten Simulation des 

Zeichengabesystems Nr. 7 (SS7-Simulator) auf der Basis von ProzefimodeUen 
und/oder konstanten Verzogerungszeiten vorgesehen ist. 

3. Simulator nach Anspruch 2, dadurch gekennzeichnet, 

30 daB der SS7-Simulator (303, 403, 503) die Komponenten SSP, Signal Transfer 
bzw. Relay Point (STP bzw. SRP) und Anbindung an den SCP durch 
ProzeBmodelle simuliert sowie SS7-Zeichenkanale zwischen SSP, STP und 
SCP durch eine konstante Verzogerung simuliert. 

35 4. Simulator nach einem der Anspriiche 1 bis 3, dadurch gekennzeichnet, 
daB ein Modul (404, 502) zur Simulation von Uberlastabwehrmechanismen 
vorgesehen ist (Uberlastabwehr-Simulator), welches die Anzahl der von 
wenigstens einem der ubrigen Simulationsmodule verarbeiteten Ereignisse in 
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Abhangigkeit von der Belastung eines oder mehrerer der SinmlatLonsmodide, 
Z.B. in Abhangigkeit von der Warteschlangenlange, und von 
benutzerdefinierbaren Parametem modifiziert; 

5 5. Simulator nach Anspruch 4, dadurch gekennzeichnet, 

daB der Uberlastabwehr-Simulator (404, 502) die Menge der von 
Verkehrssimiilator (201, 301, 401) erzeugten und/oder weitergegebenen 
Ereignisse in Abhangigkeit von der Belastung des SCP-Simulators (202, 302, 
402) steuert. 

10 

6. Simulator nach einem der Anspriiche 1 bis 5, dadurch gekennzeichnet, 
daB zur Aufstellung der NetzkonfiguratLon und/oder 
Kommunikationsdienstespezifikation wenigstens einer, vorzugsweise eine 
Mehrzahl der folgenden Parameter durch Eingabe an einem Spezifikations- 

15 Editor, insbesondere Benutzeroberflache (410), benutzerdefinierbar ist, wobei 
die Parameter in einer oder mehreren Konfigurationsdateien (207, 311, 416, 
208-212, 312-317, 411-415) gespeichert werden undbei Simulationsbeginn 
den jeweiligen Simulationsmodtden iibergeben werden: 
6.1. bzgl. der SS7-Simulation: Anzahl SSPs, Anzahl STPs/SRPs, Anzahl der 

20 Zeichenkanale zwischen STP/SRP und SCP bzw, SSP, Verzogerungen 
zwischen STP/SKP und SCP bzw. SSP, Art und/oder Anzahl der in 
verschiedenen SS7-Schichten wie MTPl, MTP2, MTP3, SCCP, TCAP 
eingesetzten Prozessoren, darauf ablaufende Prozesse mit ProzeBzeiten, 
Verzogerungen zwischen diesen Prozessoren; 

25 6.2. bzgl. der SCP-Simulation: Art und/oder Anzahl der Prozessoren (CPUs) 
eines SCP, Art der Zuweisung eines Ereignisses zu einem Prozessor (z.B. 
dienstespezifisch). Art, Dauer und/oder Piioritat im SCP laufender Prozesse, 
Art der Umsetzung eines IN-Ereignisses in eine SCP-ProzeBfolge, Anzahl 
Inkamationen eines Prozesses pro CPU; 

30 6.3. bzgL der Verkehrssimulation: 

6.3.1. allgemeine Parameter: Zeit bis zum Timeout, Verzogerungszeit bei 
Umlenkung, Anzahl Leitxmgen von und/oder zu den SSPs, Folgeanruf- 
WahrscheinHchkeit, maximale Anzahl Folgeanrufe, mittlere/maximale 
Ansagedauer, Anzahl Ansageplatze; 

35 6.3.2. dienstespezifische Parameter: mittlere Gesprachs- imd/oder 
Ansagendauer, maximale Ansagendauer, Anzahl Ansageplatze, 
Ansagewahrscheinhchkeit, Umlenk-Wahrscheinlichkeit, Anzahl Leitungen; 
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6.3.3. fiir den Dienst TV je Entscheicluiigsmoglichkeit: Startzeit, Endzeit, 
Endzeit far Folgeanrufe, Zxelwert, AnzaM Zielwerte; 
6.4. bzgl- der Uberlastabwehr-Simxilation: kritische SCP- 
Warteschlangenlange, kritische SCP-Auslastung, Dauer der Anruf-Abwehr 
5 am SSP. 

7. Simulator nach Anspruch 1 oder 6, dadurch gekemizeichnet, 

dafl der Verkehrssiinulator (201, 301, 401) IN-typische Ereigtdsfolgen 

aufgrund ganz oder teilweise benutzerdefinierbarer Angaben erzeugt, die in 

10 einer oder mehreren Dateien gespeichert sind xmd bei Simulationsbeginn dem 
Verkehrssiinulator iibergeben werden, darunter wenigstens 
7.1. Angaben zum zeitiichen Verlauf der durchschnittlLchen Verkehrsmenge in 
Anrufe pro Zeiteioheit jeweils pro zu beriicksichtigendem IN-Dienst und/oder 
Diensteteibielmier und/oder SSP, 

15 7.2. Angaben zu Wahrscheinlichkeiten betreffend das weitere Schicksal eines 

Anrufis 

7.2.1. nach Erhalt einer Weiterbehandlungsinformation vom SCP, z.B. 
mittlere Gesprachs- bzw. Ansagendauer nach erfolgreicher Vermittlimg, 
Wahrscheinlichkeiten fur erfolglose Vermittiung (Besetzt/ Teilnehmer meldet 

20 sich nicht), 

7.2.2, vor Erhalt einer Weiterbehandlungsinformation vom SCP, z.B. Timeout, 
Auflegen des Anrufers, 

wobei eine Ereignisfolge erzeugt wird, indem 

7.3. fiir jedes Simulationszeitintervall jeweils pro zu beriicksichtigendem IN- 
25 Dienst und/oder Diensteteilnehmer xmd/oder SSP unter der Annahme einer 

gegebenen Wahrscheinhchkeitsverteilung, vorzugsweise Poisson-Verteilung, 
und unter Beriicksichtigimg der entsprechend 7.1. vorgegebenen jeweOigen 
momentanen Durchschnitts- Verkehrsmenge ein Anruf bzw. Erstereignis 
(PROVIDE INSTRUCTION) erzeugt und in Abhangigkeit von der 
30 Erzeugungszeit in einen Ereigniskalender eingetragen wird, 

7.4. einem Anruf bzw. Erstereignis zugeordnete Folgenachrichten bzw. 
Folgeereignisse (EVENT, EVENT (CALL-END) unter Benicksichtigung der 
Angaben aus 6.2, erzeugt und in Abhangigkeit von der Erzeugungszeit in den 
Ereigniskalender eingetragen werden, 

35 7.5. und der Ereigniskalender somit samthche Erst- und Folgeereignisse in 
chronologischer Folge enthalt. 
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8. Simulator nach Anspruch 1, 6 oder 7, dadurch gekennzeichnet, daB 
fiir jeden vom Verkehrssiinulator (201, 301, 401) generierten Anruf bzw. 
generierte IN-Nachricht beim Dxurchlavifen des Simidators folgende 
Zeitmarken protokolliert werden: Eine Zeitmarke tl beiiu Geneiieren des 

5 Anrufs bzw. Erstereignisses, die dem Erzeugungszeitpimkt der Nachxicht am 
SSP entspricht; eine Zeitmarke t4 nach dem Abarbeiten einer Nachricht vom 
Verkehrssimulator (201, 301, 401) durch den SCP-Simulator (202, 302, 402). 

9. Simulator nach einem der Anspriiche 2 bis 7, dadurch gekennzeichnet, daB 
10 fur jeden vom Verkehrssimulator (201, 301, 401) generierten Anruf beim 

Durchlaufen des Simulators folgende Zeitmarken protokolliert werden: Eine 
Zeitmarke tl beim Generieren des Anrufs bzw. Erstereignisses, die dem 
Erzeugungszeitpunkt der Nachricht am SSP entspricht; eine Zeitmarke t2 
nach dem Abarbeiten einer Nachricht vom Verkehrssimtilator durch den SS7- 
15 Simulator (303, 403, 503); eine Zeitmarke t3 nach dem Abarbeiten einer 

Nachricht vom SS7-Simulator durch den SCP-Simulator (202, 302, 402); eine 
Zeitmarke t4 nach dem Abarbeiten einer Nachricht vom SCP-Simulator (202, 
302, 402) durch den SS7-Simulator. 

20 10. Simulator nach einem der Anspruche 1 bis 9, dadurch gekeimzeichnet, daB 
10-1. die vom Verkehrssimulator (201, 301, 401) generierten Ereignisfolgen in 
eine erste Ubergabedatei (203) eingetragen werden, die dem SCP-Simulator 
iibergeben und von diesem bearbeitet wird, wobei zu jedem Ereignis der 
Zeitpimkt tl, der dem Erzeugungszeitpunkt der Nachricht am SSP entspricht, 

25 gespeichert ist, 

10.2. die vom SCP-Simulator bearbeiteten Ereignisse in eine zweite 
Ubergabedatei (204) eiagetragen werden, die dem Verkehrssimulator 
iibergeben wird, wobei zu jedem Ereignis der Zeitpunkt t4, der dem 
Erzeugungszeitpunkt einer Folgenachricht am SCP und dem 

30 Ankunftszeitpunkt der Nachricht am SSP entspricht, gespeichert ist. (Datei- 
Modus) 

11. Simulator nach Anspruch 2, dadurch gekennzeichnet, daB 
11.1. die vom Verkehrssimulator generierten Ereignisfolgen in eine erste 
35 Ubergabedatei (304, 406) eingetragen werden, die dem SS7-Simulator 
iibergeben und von diesem bearbeitet wird, wobei zu jedem Ereignis der 
Zeitpunkt tl, der dem Erzeugungszeitpunkt der Nachricht am SSP entspricht, 
gespeichert ist. 
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11.2. die vom SST-Simulator bearbeiteten Ereignisse in eine zweite 
Ubergabedatei (305. 407) eingetragen werden, die dem SCP-Simulator 
iibergeben wird, wobei zu jedem Ereignis der Bearbeitungszeitpunkt t2, der 
dem Ankunftszeitpunkt der Nachiicht am SCP entspricht, gespeichert ist, 
5 1 1.3. die vom SCP-Simulator bearbeiteten Ereignisse in eine dritte 
tnbergabedatei (306, 408) eingetragen werden, die dem SS7-Simulator 
iibergeben wird, wobei zu jedem Ereignis der Zeitpunkt t3, der dem 
Erzeugungszeitpunkt einer Folgenachricht am SCP entspricht. gespeichert ist, 
11.4. die vom SS7-Simulator bearbeiteten Ereigmsse in eine vierte 
10 CFbergabedatei (307, 409) eingetragen werden, die dem Verkehrssimulator 
iibergeben wird, wobei zu jedem Ereignis der Zeitpunkt t4, der dem 
Ankunftszeitpunkt der Nachricht am SSP entspricht, gespeichert ist. 

12. Simulator nach Anspruch 10 oder 11, dadurch gekennzeichnet, 

15 dafi dieSchritte 10.1. und 10.2. bzw. 11.1. bis 11.4 mehrmals nacheinander 
durchgefiihrt werden, wobei beim ersten Durchlauf im Schritt 10.1. bzw. 11.1. 
zur (Jenerierung von Folgeereignissen vom Verkehrssimulator konstante SCP- 
bzw. SCP- und SS7-Verz6gerungszeiten angenommen werden, die in den 
darauffolgenden ZykLen durch die aus der zweiten bzw. vierten tfbergabedatei 

20 nach Durchlauf des SCP- bzw. SCP- und SS7-Simulators ermittelten 
Antwortzeiten modifiziert werden. 

13. Simulator nach einem der Anspriiche 1 bis 9, gekennzeichnet durch 
einen lokalen, dem Verkehrssimulator zugeordneten Ereigniskalender, in 

25 welchem vom Verkehrssimulator abzuarbeitende Ereignisse eingetragen sind. 

14. Simulator nach einem der Anspriiche 1 bis 9 oder 13, gekeimzeichnet 
durch 

einen lokalen, dem SS7-Simulator zugeordneten Ereigniskalender. in 
30 welchem vom SS7-Simulator abzuarbeitende Ereignisse als Funktion ihrer 
Zeitmarke und/oder Prioritat eingetragen sind. 

15. Simulator nach einem der Anspriiche 1 bis 9, 13 oder 14, gekennzeichnet 
durch 

einen lokalen, dem SCP-Simulator zugeordneten Ereigniskalender, in 
35 welchem vom SCP-Simulator abzuarbeitende Ereignisse als Funktion ihrer 
Zeitmarke und/oder Prioritat eingetragen sind. 
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16. Simulator nach emem der Aaspriiche 13 bis 15, dadurch gekeimzeichnet, 
daB ein lokaler Ereigniskalender mehrere ineinander geschachtelte 
Warteschlangen aufweist, die jewdls von einer Unterkomponente des 
Simulationsmoduls abzuarbeitende Ereignisse enthalten. 

5 

17. Simulator nach einem der Anspriiche 13 bis 16, gekennzeichnet durch 
einen globalen Ereigniskalender, der Ereignisse, die Nachrichten zwischen 
SSP, SCP und gegebenenfalls dem SS7-System entsprechen, (globale exteme 
Ereignisse) und Verweise auf die lokalen Ereigniskalender der Module 

10 Verkehrssimulator und/oder SCP-Simulator und/oder SS7-Simulator (globale 
interne Ereignisse) als gemeinsame Warteschlange enthalt, wobei die 
Ereignisse als Funktion der Zeit und/oder der Prioritat in den globalen 
Ereigniskalender eingetragen werden. (Online-Modus) 

15 18. Simulator nach Anspruch 17, dadurch gekennzeichnet, 

daB zur Beriicksichtigung von rufunabhangigen Vorgangen innerhalb der 
Netzkomponenten, z*B, Betriebssystemeingriffen innerhalb der SCP- 
Prozessoren, rufimabhangige Ereignisse zufaJHg erzeugt, in den globalen 
sowie gegebenenfalls den entsprechenden lokalen Ereigniskalender 

20 eingetragen und vom jeweiligen Simulationsmodul abgearbeitet werden. 

19. Simulator nach einem der vorangegangenen Anspniche, dadurch 
gekennzeichnet, 

daB dem Simulator und den Simulationsmodulen jeweils eine Simulationsuhr 
25 zugeordnet ist, welche wahrend des Abarbeitung eines Ereignisses aus dem 
^obalen bzw. dem jeweiHgen lokalen Ereigniskalender stillsteht und bei 
dessen Beendigung auf den Zeitpunkt des nachsten, im entsprechenden 
globalen bzw. lokalen Ereigniskalender eingetragenen Ereignisses vorgestellt 
-wird. 

30 

20. Simidator nach einem der vorangegangenen Anspriiche, dadurch 
gekennzeichnet, 

daB ein Simulationsmodul einer extemen Nachricht bzw. einem extemen 
Ereignis benutzerdefinierbar eines oder eine Folge von intemen Ereignissen 
35 mit jeweUs definierter Dauer At, zuordnet und die Einzelereignisse in den 
lokalen Ereigniskalender eintragt. (Erzeugung eines intemen Ereignisses) 
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21. Simulator nach Anspruch 20, dadurch gekennzeichnet, daB 

21-1. ein Simulationsmodul durch ein in den globalen Ereignisfcalender 
dngetragenes internes Ereignis, das auf den lokalen Ereigniskalender 
verweist, zur Abarbeitung seines nachsten intemen Ereignisses aufgerufen 
5 wird, 

21.2. nach Abarbeitung des Ereignisses die interne Simulationsuhr angepaflt 
wird, wobei 

21.3.1. ein weiteres zu der ProzeBkette gehoriges Ereignis vorhanden ist, 
ein Verweis auf dieses folgende interne Ereignis mit der aktueUen intemen 

10 Simulationszeit in den globalen Er^gniskalender eingetragen wird 

21.3.2. Oder, falls das aktuell bearbeitete Ereignis das letzte einer ProzeBkette 
darstellt, ein extemes Ereignis vom Simulationsmodul erzeugt und mit der 
aktueUen intemen Simulationszeit in den globalen Ereigniskalender 
eingetragen wird. 

15 

22. Simidator nach einem der vorangegangenen Anspriiche, dadurch 
gekennzeichnet, 

daB Telefon-Normalverkehr in die Verkehrssimulation einbezogen wird. 

20 23. Simulator nach einem der vorangegangenen Anspriiche, dadurch 
gekennzeichnet, 

daB in konstanten ZeitintervaUen oder fiir vorbestimmbare 
Simulationszeitpunkte wenigstens eine der folgenden Netzauslastungs- 
GroBen mit der dazugehorigen Simulationszeit in eine Ausgabedatei 
25 geschrieben werden: 

Anzahl der vom Verkehrssimulator erzeugten, in das IN gelangenden Anrufe 

pro Zeiteinheit, 

Anzahl der Nachrichten, die sich in Bearbeitung im SS7-Simulator auf dem 
Weg zum SCP-Simulator befinden, 
30 Anzahl der Nachrichten im SCP-Simulator, 

Anzahl der Nachrichten, die sich in Bearbeitung im SS7-Simulator auf dem 
Weg zaim Verkehrssimulator befinden, 

24. Simulator nach einem der vorangegangenen Anspriiche, dadurch 
35 gekennzeichnet, 

daB der SCP-Simulator in konstanten ZeitintervaUen oder fiir vorbestimmbare 
Simulationszeitpunkte die CFU-Auslastung und/oder Warteschlangenlange 
und/oder Anzahl bearbeiteter Prozesse pro Zeiteinheit (Dispatches), jeweils 
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individualisiert nach CPU-Nummer und/oder gemittelt iiber alle CPUs 
und/oder minimaler und maximaler Wert einer CPU als SCP:Statistik-Gr6Ben 
mit der dazugehorigen Simulationszeit in eine Ausgabedatei schreibt, 

5 25. Simulator nach einem der vorangegangenen Ansprxiche, dadurch 
gekennzeichnet, 

daB in konstanten Zeitintervallen oder fur vorbestimmbare 
Simxilationszeitpunkte SSP-spezifisch die Anzahl der belegten Leitungen zu 
einer Vermittlungsstelle und/oder im IN protokoUiert und in eine Datei 
10 geschiieben wird. 

26. Simulator nach einem der vorangegangenen Anspriiche, dadurch 

gekennzeichnet, 

daB eine Benutzeroberflache vorgesehen ist, die als Eingabeelement zur 
(Jenerierung einer Simulation durch Eingabe von Simidationsparametem 
15 dient, die Verwaltung der Konfigurationsdateien vomimmt sowie imstande 
ist, die Simulationsergebnisse graphisch auszugeben. 

27. Simulator nach einem der vorangegangenen Anspriiche, dadurch 
gekennzeichnet, 

20 daB ein Modul zur ereignisorientierten Simulation weiterer Netzkomponenten 
vorgesehen ist, insbesondere era Modul zur Simidation des Service 
Management Systems (SMS) und/oder zur Simtilation von InteUigenten 
Peripherals (IPs). 
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